RE: error handling
RE: error handling
- Subject: RE: error handling
- From: "Nelson Santos" <email@hidden>
- Date: Tue, 12 Jun 2007 10:16:39 -0400
- Importance: Normal
Hi Kirk,
Thank you very much for your reply. What you are saying makes sense. As I
replied to Nima's email, the Cocoa frameworks throw an exception when trying
to access an NSArray element beyond the bounds of the array. This, to me,
seems like a trivial situation, akin to passing a method the wrong argument.
Do I throw an exception? Do I return a nil/zero? How do I decide? I agree
that exceptions should be kept at a minimum, but when does it make sense to
use them?
I think the idea of making sure the program continues to run regardless of
the error is a good one. I will strive for that as well.
What do you do in your programs when a method receives a value it didn't
expect (a value not originating directly from the user) which doesn't
warrant a shutdown of the application? According to your email, it sounds
like you don't notify the user. Do you log it? How do you as a developer
learn of these problems that are encountered in release versions of your
software if the user doesn't know to report it?
A single exit from every method is a very good idea. I've had many
developer friends preach the same thing.
Thanks again!
Nelson
-----Original Message-----
From: Kirk Kerekes [mailto:email@hidden]
Sent: Tuesday, June 12, 2007 7:20 AM
How you handle errors very much depends on the target market for your
software, which you have not defined. The standards for a scientific/
medical application are different from the standards for a server
which are different from the standards for a consumer utility.
If you use the Cocoa frameworks as a model, most anticipated
erroneous results/errors are indicated by a nil or NSNotFound return
value. A small minority are indicated via an exception.
In my own code I treat continuing to run as a priority.
Cocoa routines that are documented as returning exceptions under some
conditions are wrapped in simple exception handlers that log the
exception and then return a nil, NSNotFound or default value
depending on the circumstances. Cocoa routines that return a nil or
NSNotFound value are wrapped in if-else logic that is much like the
exception logic described above. If it is impossible to proceed
without the return result from a routine, I retry or notify the user.
If one of my methods is sensitive to input values, I check them on
input, and (generally) return NSNotFound or nil if the input value is
unsafe.
Often this check is integrated into the method logic, using a default
(failure) return value set on entry, and over-writing that value when
a valid code path is followed:
- (id) aMethod:(id) thing
{
id result = nil;
if(thing)
{
[code that may or may not overwrite result here]
}
return result;
}
All of my methods rigorously follow the single-exit model -- there is
never more than one return statement in a method.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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