Re: Professional Error Handling
Re: Professional Error Handling
- Subject: Re: Professional Error Handling
- From: Jens Alfke <email@hidden>
- Date: Mon, 26 Oct 2009 08:30:14 -0700
On Oct 25, 2009, at 3:44 PM, Dick Bridges wrote:
FWIW, there are some people (myself included) that consider "error
numbers" to be something of an anti-pattern when exception handling
is available. Because of [IMHO] improvements in gcc, Objective-C now
supports exception handling and it might be worth your time to
investigate how exceptions work.
I happen to agree with you in general, but if you do this in a Cocoa
app you're going against the grain of the frameworks, which will make
your life somewhat more difficult. These are issues that come up
whenever you try to use exceptions in any framework that doesn't use
them:
First, every time you call a framework function that returns an
NSError, you're going to have to add a call to a function of your own
that looks at the NSError* and throws an exception if it's non-nil.
That's annoying, and causes intermittent problems if you forget it.
Second, you should not throw any exceptions out of your code into
framework code, or you'll unwind the stack frames of Cocoa methods
that may need to do cleanup after your call returns. This is very
likely to result in memory leaks in a non-GC app, and a lot of worse
things can happen. I have had to debug problems like this in the past,
and they can be really, really, really nasty to track down.
To prevent that, you have to consider what all of your methods are
that could be called from framework code, and wrap each of those in an
@try block, with an @catch that calls another utility function to
convert the exception into an NSError and return it.
Now you have the problem that all of these methods in your code have
different semantics, in that they no longer throw exceptions. So your
code now has two types of exception handling, which you have to take
into account when calling into your own methods...
It's rather a mess. I would strongly urge you to avoid it unless you
have a very clear distinction between your own code and the
frameworks, i.e. this is some kind of back-end code that has one or
two clear entry points and no callbacks.
—Jens
PS: Also, using exceptions doesn't mean not having error numbers. I
know Java uses an entire class hierarchy for this, but that turns out
to be fairly wasteful, as classes cost time and memory to initialize
at runtime. Moreover, you then have the problem of mapping a class to
an error message when displaying alerts; it's easier to map error codes._______________________________________________
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