Re: NSError: why returned directly?
Re: NSError: why returned directly?
- Subject: Re: NSError: why returned directly?
- From: Jonathon Mah <email@hidden>
- Date: Thu, 27 Apr 2006 00:41:58 +0930
Erik, Ondra, Joar,
On 2006-04-26, at 23:37, Erik Buck wrote:
There is a difference between expected “reasonable” errors and
exceptions. For example, trying to create a file on a full file
system is an entirely predictable error. It is an expected error.
Attempting to access an index beyond the end of an array is an
expected error. Even though Foundation raises an NSRangeException
or NSInvalidArgumentException, I don’t think it should.
The whole error/exception distinction currently in Cocoa feels too
hazy. What divides programmer errors and runtime errors? Erik
suggests an illegal array index is a runtime error, but I shudder at
the thought of [array objectAtIndex:error:].
Ondra raises some good points. Using @throw for errors would avoid
the manual stack unwinding. It could also give you a nicer way to
hook into errors in the debugger; breaking on -[NSException raise] is
easy, but is there any way to break on an error?
On the other hand, I think a by-reference style fits well in cases
such as key-value validation:
- (BOOL)validateValue:(id *)ioValue forKey:(NSString *)key error:
(NSError **)outError
You might just want a boolean answer as to whether a value is valid
or not, or you might be interested in the error if, say, UI is
involved. Using @throw here would unwind without a return value; I
don't think that is appropriate.
The validation method _is_ unusual in its usage of by-reference
parameters, so perhaps it's an exception. :)
Finally, a question about error style: If a method succeeds and an
error parameter was passed in, should the error parameter be set to
nil or left unchanged?
Jonathon Mah
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden