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 (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
