On Jul 16, 2009, at 18:33, Timothy Wood wrote:
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.
Well, I admit I wasn't thinking straight when I wrote that, but I'm
gonna stand by it (except it should be NULL not nil). If I was doing
something like this, I'd have the macro *assume* the method's output
parameter is called 'outError', and make the first macro parameter be
the thing to encapsulate instead. That covers some useful ground:
First, it allows cases where you need to use an auxiliary NSError:
NSError* error;
if (![... error: &error] && error.code != something) {
OBError (&error, ...)
return NO;
}
and, second, it produces a compile error if the enclosing method
*doesn't* have an outError parameter, which addresses the concern in
your other post. I don't know about you, but *all* my outErrors *are*
called "outError" anyway, because it cheaply documents the error
handling "protocol" in effect.
Anyway, perhaps we've done this to death. I understand your point of
view now. (But by all means have the last word if you wish.)
Heh. I worked with Wil long enough that I can't be sure whether he
started that approach at Omni, or Ken or me.
Ah, apologies for not apportioning the credit fairly ... and thanks
for foisting this on the world. :)
_______________________________________________
Cocoa-dev mailing list ([email protected])
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]
