Re: macOS 10.13 suggestion for init() throws
Re: macOS 10.13 suggestion for init() throws
- Subject: Re: macOS 10.13 suggestion for init() throws
- From: Daryle Walker <email@hidden>
- Date: Tue, 28 Feb 2017 14:56:31 -0500
> On Feb 28, 2017, at 12:27 PM, Jens Alfke <email@hidden> wrote:
>
>
>> On Feb 28, 2017, at 4:56 AM, Daryle Walker <email@hidden <mailto:email@hidden>> wrote:
>>
>> Could we have a NSDocument.init() that throws in the next macOS? That would translate to a "initWithError" in Objective C (I think). It would be the new primary initializer, with the current one calling it and dropping any error to oblivion.
>
> If you’re doing anything that might fail, you should do it in an override of one of the other NSDocument initializers, which do return errors. The basic -init method is explicitly documented as not allowing failure.
The no-parameter initializer for NSDocument is for code that is common to the other initializer calls (which are directly called from NSDocumentController). Those initializers can throw, so if your common initialization code has throwable elements, you need to save it in an (optional) Error object, then check and throw it in the other initializer. The problem here is an interface mismatch where Swift has function throw-ability status out-of-band from that function’s parameter list, while Objective-C doesn’t. Since Objective-C uses a gentleman’s agreement to handle any errors through an extra parameter, its initializers can’t simultaneously be parameter-less and throw-able. My experience with this workaround inspired me that we can improve the interface w.r.t. Swift.
—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden