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 myNumresults = [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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
