Re: exception in init
Re: exception in init
- Subject: Re: exception in init
- From: Andreas Grosam <email@hidden>
- Date: Wed, 04 Apr 2012 18:29:24 +0200
On Apr 4, 2012, at 5:57 PM, Jens Alfke wrote:
>
> On Apr 4, 2012, at 8:37 AM, Andreas Grosam wrote:
>
>> In a "debug" version, use NSAssert and friends (ensure Preprocessor macro "NS_BLOCK_ASSERTIONS" is not defined). Use Unit tests in order to detect *any* possible logic error. In a "release" version where NSAsserts and friends may become no ops, this may possibly ensure that no invalid parameters will be ever passed to the method.
>
> I don't think NS_BLOCK_ASSERTIONS is normally set for you in a Release build. Of course you can change the project settings to do so, but I don't know how common that is — Apple generally ships its apps and frameworks with assertions enabled, and I've never turned them off in anything I've written.
>
>> However, if you cannot guarantee that - or if you find this assumption too hairy - the best you probably can do is:
>>
>> if (url == nil) {
>> NSLog(@"FATAL ERROR: invalid parameter in initWithURL:");
>> abort();
>> }
>
> I disagree.
> First, if the developer is turning off assertions, it's because s/he doesn't want the overhead (in code size and runtime) of these kinds of checks. So except in very unusual circumstances you should honor that and not force your check to happen anyway.
The macro NS_BLOCK_ASSERTIONS is strictly set per translation unit. If it is set as "Preprocessor Macro" in the build setting, it will be set for all translation units of the target. If this is a library or framework where the init method resides, then it would have been set in the library or framework build setting by the *library developer* and she might have good reason for doing so or not.
That is, whether this macro is defined or not is a decision of the library developer. The client can not change this, nor does the library developer know whether the macro is set in the client code.
>
> Second, calling abort() is way too harsh. Call +[NSException raise:] instead. That way the caller has some chance of handling it, and Lion can put up it's nifty an-exception-occurred alert, and the app doesn't just go "poof" in front of the user.
The problem on Mac OS X in Cocoa Apps is, that there is no alert. The application also does not stop, or terminate gracefully. The default behavior of the event loop is to log an error message, and then **continue**.
Note, this is the default behavior. If you want to handle exceptions and possibly terminate the app, AFAIK it requires a very elaborated procedure, unless someone proves me wrong, and shows a simple code snippet how to terminate gracefully after encountering an exception.
On the other hand, returning nil in an init method can cause other issues (subclass instances may receive a dealloc message, yet its ivars are not yet initialized). This has been discussed recently - in the Objective-C list, if I remember correctly.
Regards
Andreas
_______________________________________________
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