Re: When to use exception handling?
Re: When to use exception handling?
- Subject: Re: When to use exception handling?
- From: Jens Alfke <email@hidden>
- Date: Sat, 28 Nov 2009 13:47:39 -0800
On Nov 28, 2009, at 1:29 PM, Helen Cooper wrote:
> "exceptions are resource-intensive in Objective-C"
In the 32-bit runtime, @try is fairly expensive (it has to save all the CPU registers to the stack), so you pay for exception handling even if no exceptions are thrown.
In the 64-bit runtime, @try is basically free, but @throw is very expensive. (This is the same kind of "zero runtime overhead" exception system used by C++ and Java.)
> "Conditions giving rise to exceptions are due to programming errors; you should deal with these errors before you ship a product."
True, for the most part. Cocoa APIs tend not to use exceptions to signal errors that can legitimately occur at runtime, like reading past the EOF of a file or failure to decode a string. Instead they're only used for situations that should never occur, like array index out of bounds or sending an unrecognized message to an object.
This is a different design than most other OOP frameworks, which will use exceptions for 'exceptional' but legitimate conditions. In terms of Java, it's as though Cocoa has no checked exceptions, only RuntimeExceptions.
There are a few exceptions, mostly when you use Distributed Objects — a failure to send a message to a remote object is raised as an exception, so you have to use exception handling with any call that might involve remote objects.
> Taken together, I am thinking that:
> 1. it makes sense to use exception handling to force myself to think about likely exceptional conditions
> 2. however, final production code should not contain exception handling routines, as I should instead eliminate the potential for exceptions to occur
I tend to leave exception handling in, as long as it's not in some really time-critical inner loop. Even a shipping app will contain bugs, inevitably, and having some exception handling can make the difference between your app recovering gracefully, vs. crashing. A user who had unsaved changes will really appreciate if they get a chance to save after the error occurs.
Most importantly, if you write any C callback functions, or methods invoked as the top level of an NSThread, these should be wrapped in @try...@catch blocks. If any exceptions are thrown out of such code, your app will bomb.
I have some utility code that helps out with catching and reporting exceptions in Cocoa apps:
http://bitbucket.org/snej/myutilities/src/tip/ExceptionUtils.h
—Jens_______________________________________________
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