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.
There's one exception that comes to mind that's bitten me a few times:
NSFileHandle. It throws an exception whenever there's a problem and
what's worse (IIRC) is that it doesn't give you an error code—just an
error string. I now use a category method of my own:
availableDataOrError: instead of the availableData method.
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.
At the risk of sparking debate, I definitely prefer the philosophy
that Cocoa tends to use. It's too easy to forget to handle exceptions
whereas you're forced to handle an error condition if something
explicitly returns an indication. If you want exceptions to be thrown
you can easily wrap the code to do that. (You can of course wrap code
that throws exceptions to return errors instead, but I think this is
more unpleasant than the other way round.) Part of my attitude on this
comes from C++ where I think it's difficult to make code exception safe.
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden
This email sent to email@hidden
