On Jun 10, 2010, at 1:58 PM, Frederick C.Lee wrote: > Is it acceptable to merely trap for the out-of-bound exception within the > method() and continue my way? > ... or should I test EVERY TIME I access a member, to see if the member exist?
For better or worse, Cocoa’s policy policy is that an exception represents a programmer error, i.e. a bug. (Except when it doesn’t.*) I don’t agree with this, although I don’t go as far as the Python “ask forgiveness, not permission” philosophy in which exceptions can get thrown during normal usage. The major reasons not to let the exception occur and then catch it are: * Exceptions are pretty slow. In the 32-bit runtime it’s the �...@try” statement that’s slow (it has to copy the entire CPU state into a struct on the stack). In 64-bit, I think the runtime uses a “zero-overhead” system like C++ in which �...@try” is basically a no-op, but throwing the exception is very, very expensive due to the need to examine the binary code corresponding to every stack frame. * “Noise” exceptions like these get in the way of debugging the serious exceptions that you’ll get due to bugs in your code. They’ll get caught by Xcode’s “Break on exceptions” setting, making it less useful for catching bugs. * Exceptions create a complex flow of control that can be difficult to understand. For example, it’s easy to add code to the inside of an @try block later on and not consider the implications of what happens if an exception is thrown before that code is reached. I wouldn’t add them if it’s not necessary. —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
