Re: odd behavior with NSError?
Re: odd behavior with NSError?
- Subject: Re: odd behavior with NSError?
- From: Bill Bumgarner <email@hidden>
- Date: Thu, 15 Oct 2009 22:56:14 -0700
(response is pedantic for the purposes of the archive :)
On Oct 15, 2009, at 10:41 PM, Nathan Vander Wilt wrote:
Ouch. So the following pattern is incorrect?
Yes; it is incorrect.
NSError* internalError = nil;
(void)[foo somethingReturningBool:bar error:&internalError];
if (internalError) {
// ...
}
Specifically, assuming anything about the value of 'internalError'
without first determining the return value of -
somethingReturningBool:error: returned a value indicating an error
(typically NO/0/nil/NULL) is an error.
I got into this habit because most every method is documented to say
things like "parameter used if an error occurs" and "May be NULL".
You're saying that some methods go out of their way to trample my
(potentially unavailable) error storage even on success? I'm
starting to worry that I'll spend tomorrow fixing much old code
instead of getting to make new mistakes...
They don't go out of the way to trample it, but may trample it as a
part of whatever internal implementation they use.
I have, however, debugged several bugs that have boiled down to code
assuming the NSError**'s value is definitively indicative of an error.
In one case, a method that takes an (NSError **) argument may call
other methods that take the same, it might -- as an implementation
detail -- pass the argument through, maybe even one of those returns
"hey, man, an error occurred", and the caller might recover from it
and eventually return success, but not actually clear the error value
in the process (because there is no need to do so, by definition of
the API).
A similar problem occurred when the NSError** was set up to describe
some problem, later corrected, and then the error was released.
Success was returned, but the caller assumed the error was valid...
*boom*.
b.bum
_______________________________________________
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