I often write methods that take an (NSError**)error_p argument. In
the documentation of Apple methods that do this, I read that the
NSError** will be set if there ^is^ an error, but most do not specify
what will happen if there is ^not^.
When there is no error, if I'm provided a non-NULL error_p, I like to
set *error_p to nil before returning, so that the invoker can use
(*error_p==nil) after my method returns to check for no error. Now,
Chris Hanson wrote once that this check is not a recommended idiom,
and that, to indicate no error, a method should set its return value
to YES. But even when I return YES or NO as he recommends, I don't
like the idea of leaving the error_p undefined, so I pre-set *error_p
to nil at the beginning of my methods.
Now I wonder if someone might expect NSError** to remain untouched,
maybe preserving some previous error. Usually you bail out
immediately and would not invoke any more methods after an error
occurs, but does anyone know a good reason to not set *error_p = nil
in case of no error?
_______________________________________________
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]
