Re: Uncaught exceptions thrown by Cocoa documented anywhere?
Re: Uncaught exceptions thrown by Cocoa documented anywhere?
- Subject: Re: Uncaught exceptions thrown by Cocoa documented anywhere?
- From: Chris Hanson <email@hidden>
- Date: Fri, 15 Feb 2008 19:58:37 -0800
On Feb 15, 2008, at 11:32 AM, Bill Bumgarner wrote:
On Feb 15, 2008, at 11:15 AM, Adam P Jenkins wrote:
Writing exception-safe code is similar to writing thread-safe code
in that it's a lot easier if you've considered it throughout the
code's lifetime rather than trying to introduce it late in the
codebase's life. Given that exceptions were only recently added to
Objective-C, it's not surprising that most existing ObjC code isn't
exception-safe.
Exceptions have been in Cocoa since the late '80s...
@try/@catch/@finally was a relatively recent addition in the last
few years, but the NS_DURING/NS_HANDLER/NS_ENDHANDLER served that
purpose prior.
However, when the old-style exception macros were introduced, the
unfortunate decision to base them on setjmp rather than to extend the
language to make them zero-overhead-unless-thrown ("zero-cost" in the C
++ and Java world) ensured that they weren't very widely used because
every NS_DURING/NS_HANDLER/NS_ENDHANDLER incurred a significant
performance penalty and required marking variables as "volatile" for
correctness etc.
I think this even more than historical legacy is what prevented
OpenStep from being exception-safe at its introduction in 1994; after
all, it had to run reasonably on 25MHz 68040 hardware with 32MB (or
even less) memory.
Truly modern language-level exceptions -- which allow variables to be
marked volatile automatically by the compiler, which allow type-based
rather than name-based matching of exceptions to handlers, and which
can have a transparent zero-cost implementation -- really were only
added to Objective-C in Mac OS X 10.3 in 2003. And it took until the
introduction of the 64-bit Objective-C runtime to actually ship zero-
cost exceptions.
Alas, all this is despite exceptions being an established best
practice for safe error propagation and recovery since the mid-1970s
in academia (aka Lisp, Ada and functional languages), and since the
early 1990s in the C++ community (and subsequently in the Java
and .NET communities).
Which is really too bad, because pervasive exception-safe code makes
it very easy to cleanly propagate errors across layers of a system to
the point at which it's appropriate to handle them. Instead right
now, if something deep inside your code can return an NSError,
everything between the call that can return the error and your UI
needs to be able to propagate it out. It's the bad old days of OSErr
or HRESULT propagation all over again, where every call has to be
wrapped in an "if" block and every method has to return a result code
that the next layer checks.
-- Chris
_______________________________________________
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