But the Cocoa architects basically dislike exceptions, and the Cocoa
frameworks (with a very few exceptions) raise exceptions only to
indicate *programmer errors*: passing an illegal value to a
parameter, accessing an invalid array index, calling a nonexistent
method, etc. (It's roughly like the distinction between checked and
unchecked exceptions in Java.) So exceptions aren't part of the API,
they're just a mechanism for code to bail out if something illegal
happens.
I don't happen to agree with this philosophy (and have been involved
in too many internal debates about it...) but that's the way it is.
Two additional points -- neither of which are intended to express my
particular philosophy or opinion regarding exception handling:
(1) In the 32 bit [Legacy] Objective-C ABI, creating an exception
handler is very expensive; CPU cycles and chunks of memory are
consumed. Thus, having loads of exception handlers floating around
your code in the Java-esque style of exceptions-as-error-execution-
path can incur a measurable and noticeable performance impact.
(2) That Cocoa is implemented with the philosophy as described by Jens
means that you will generally benefit -- your code will generally be
simpler, easier to maintain, and work better across versions of the
system -- if you follow the same implementation pattern, regardless of
personal beliefs.
If you do decide to go the java-esque route of using exceptions to
encapsulate and perpetuate user level erroneous conditions, make
damned sure you do not toss exceptions through frames contained with
Cocoa.
