Re: Throwing an error from a NSDocument.init override

2017-02-15 Thread Quincey Morris
On Feb 15, 2017, at 00:29 , Daryle Walker wrote: > > Apple’s code will call my versions instead of the ones in NSDocument, right? Yes, because your subclass initializers are (from the Obj-C perspective) overrides, or (from the Swift perspective) the only visible ones for your

Re: Throwing an error from a NSDocument.init override

2017-02-15 Thread Daryle Walker
> On Feb 14, 2017, at 1:24 PM, Quincey Morris > wrote: > > On Feb 14, 2017, at 00:26 , Daryle Walker > wrote: >> >> But I can’t call the “super” versions of those other initializers from >> within my override. >

Re: Throwing an error from a NSDocument.init override

2017-02-14 Thread Quincey Morris
On Feb 14, 2017, at 00:26 , Daryle Walker wrote: > > But I can’t call the “super” versions of those other initializers from within > my override. This is the essence of your problem. Your “override” cannot be a convenience initializer because convenience initializers cannot

Throwing an error from a NSDocument.init override

2017-02-14 Thread Daryle Walker
The parameter-less version of “init” in NSDocument can’t throw. It’s suggesting to (save the error somehow and then) throw the error from one of the other initializers. This counts on the fact that you won’t initialize a NSDocument (subclass) instance with no parameters, but call one of the