On Apr 19, 2008, at 11:46 AM, Jerry Krinock wrote:
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?
If there is no error -- if the return value is set and valid -- then
the behavior regarding the (NSError**) argument is undefined.
Any caller relying upon the value to be set, unset, changed, or
unchanged is implemented incorrectly.
Likewise, the value of NSError** should *always* be considered an
uninitialized value upon entry to a method or function that takes an
NSError** argument.
Keep in mind, also, that a caller may pass NULL as the NSError**
argument, indicating that it isn't interested in the details of the
error, but only whether or not call succeeds or fails.
As such, you are certainly free to do something like:
- (MyClass *) getSomething: (NSError **) anError
{
if (anError) *anError = nil;
... do some stuff ...
if (... error happened ...) {
*anError = [NSError ...];
return nil;
} else {
return ... some result instance ....;
}
}
As the caller of your own method, do not rely on *anError being set to
nil. Doing so creates an impedance mismatch with the rest of Cocoa's
behaviors and, thus, is simply asking for trouble.
b.bum
_______________________________________________
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]
