Re: argument checks
Re: argument checks
- Subject: Re: argument checks
- From: Jens Alfke <email@hidden>
- Date: Thu, 12 Jun 2008 08:22:47 -0700
On 11 Jun '08, at 10:50 PM, Ashley Perrien wrote:
NSNumber *myNum;
// Lots of code where I've forgotten to actually do anything with
myNum
results = [myClass someCalculationUsing: myNum];
Turn on the "Uninitialized Automatic Variables" warning in your
project's build settings. (Actually you can only turn it on in a
Release target, because it requires that optimization be enabled.)
Then you'll get a compiler warning in a case like this. It helps if
you also turn on "Treat Warnings As Errors" so you can't accidentally
ignore the warning, too.
If this was a function/method parameter, that warning won't be useful;
but there is also an "Unused Parameters" warning that will tell you
about that situation.
Jason Coco wrote:
assert( myNum != nil );
It's a bad idea to use that function, IMHO. Its effect is to simply
kill the entire process; the user doesn't even get an "unexpectedly
quit" alert. That's a bad user experience. The NSAssert family of
macros are better because they raise an exception — this will usually
be caught by the Cocoa frameworks and the app can keep going. You can
add a handler to your application and put up an alert to warn the user
that something went wrong, so s/he can save and quit ASAP.
—Jens
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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