Must ... avoid ... replying ...
Willpower ... draining ...
"Reply" button ... growing ... looming ... throbbing ... AUUUGH!
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.
I find it's the other way around: you can ignore errors when they're
just numbers being returned by a function. All you do is forget to
assign the return value to a variable, or check that variable.
(Especially since the world is full of sample code that does exactly
that.) But you can't ignore an exception without explicitly wrapping
an empty try/catch block around it.
Moreover, exceptions are more consistent than code that sometimes
returns a boolean, sometimes an error number, sometimes an 'out'
struct. And if you want to set a breakpoint when an error occurs (an
extremely useful debugging technique) it's easy to do with exceptions,
much harder with error codes unless you wrap every function in some
kind of "checkError( )" call.
If nothing else, I think the fact that every other major OOP language/
framework uses thrown exceptions is pretty significant. Cocoa's
philosophy is, I think, a holdover from the early days of NeXT before
there were exceptions; changing the APIs to use them in a meaningful
way would have been too difficult, especially for developers rewriting
their apps, so they adopted them only to the extent of using them as a
recoverable assertion mechanism.
OK, that's all. (That nice Dr. Zimmerman would like me to tell
everyone that the Shady Dell Sanatorium will not be passing any
replies on to me, for the duration of my rehabilitation program.
Thanks for your support.)
