Re: Core Data debugging
Re: Core Data debugging
- Subject: Re: Core Data debugging
- From: Timothy Wood <email@hidden>
- Date: Thu, 16 Jul 2009 18:33:58 -0700
On Jul 16, 2009, at 5:44 PM, Quincey Morris wrote:
In the second case, you're not screwed because of "these NSError
rules" but because you're using an output parameter of the method as
an input parameter to the macro. It's a plain bug, unless you assert
it not to be a bug (which is basically what you're doing, which is
why I'm calling it "weak").
Yes, it is a bug -- maybe I've not been clear enough: I know we
have to follow the rules Apple has set forth. This isn't in debate.
My point is that the code *was* correct before someone came along
and edited and the rules introduce needless fragility and verbosity.
If the rules were changed, then the code would be shorter and less
fragile in the face of editing. The ideal rules would lessen
verbosity, fragility and aid static analysis with clang-sa.
and if there's something to do that doesn't return a NSError:
if (![... do something ...]) {
OBError (nil, ...);
return NO;
}
Um, no. This doesn't fill *outError if you pass nil. Either way,
you'd end up having to tweak code more as it got moved about.
What's so fragile about that? If you paste it somewhere else, the
'nil' goes with it. :)
And if I move it to a place that does have a NSError-based API (or
maybe I update the API its calling to have an outError), then I have
to tweak it to avoid dropping the underlying error.
Is the return-YES-on-success pattern really reasonable for most non-
trivial methods?
I should confess my bias here. I'm a big fan of Wil Shipley's
"mainline" code approach:
http://www.wilshipley.com/blog/2005/07/code-insults-mark-i.html
Heh. I worked with Wil long enough that I can't be sure whether he
started that approach at Omni, or Ken or me. Anyway, I've been doing
early out for nearly two decades. I do, also sometimes early-out on
YES if the remainder of the code is for final error handling. Sorry
if it was distracting from the main point here.
-tim
_______________________________________________
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