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 convention as described makes the method author handle
more rough corners in order to simplify the method caller's job, which
is the usual trade-off for this sort of thing.
You could write an error macro pair that fails at compile time if you
forget the first half.
#define OBBaseError(var) \
const int you_forgot_OBBaseError_##var = 0; \
if (var) *var=0
#define OBError(var, whatever) \
if (you_forgot_OBBaseError_##var) abort(); \
/* do your stuff with var */
OBError(outError);
// oops, forgot OBBaseError(outError);
// test.m:18: error: 'you_forgot_OBBaseError_outError' undeclared
--
Greg Parker gpar...@apple.com Runtime Wrangler
_______________________________________________
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 arch...@mail-archive.com
