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.
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.
—Jens
_______________________________________________
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
