Re: Core Data debugging
Re: Core Data debugging
- Subject: Re: Core Data debugging
- From: Ben Trumbull <email@hidden>
- Date: Thu, 16 Jul 2009 19:35:45 -0700
On Jul 16, 2009, at 4:49 PM, Timothy Wood wrote:
Sure, I should remember to ignore it or initialize it to nil myself
or have a OBBaseError macro, but one day I'll forget. The current
rules make me write more and more fragile code than I'd need to if
we could just all depend on setting NSError locals to nil before
passing them down. I know we can't right now, but I'm saying that
makes life harder than it could be. Cocoa is supposed to round off
the rough corners in programming! =)
The alternative would be to require the caller to set `err=nil` before
calling `whateverWithError:&err`. And of course one day you would
forget.
The caller must initialize the NSError to nil anyway. Leaving
uninitialized local variables lying around waiting to bite you is
simply crazy.
The original problem in this thread was:
NSError* err;
BOOL result = [someObj whateverWithError:&err];
if (!result) {
// do something with error
}
Now, you're hosed when someObj is nil. Lots of people, especially
people new to Cocoa unused to ObjC "helping" you will nil dispatch,
make this mistake. Unless you always check for nil too, which I've
never seen anyone do. Basically you either must do:
NSError* err = nil;
or every check must be
if (!result && receiver)
What with all this "one day you would forget" silliness, leaving an
uninitialized local variable lying around is begging for failure to
come smack you in the face.
- Ben
_______________________________________________
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