> On Feb 28, 2017, at 12:27 PM, Jens Alfke <j...@mooseyard.com> wrote: > > >> On Feb 28, 2017, at 4:56 AM, Daryle Walker <dary...@mac.com >> <mailto:dary...@mac.com>> 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
