Question

Reading the documentation and going through the Apple sample codes (and most of the third party Objective-C code available out there), I get the impression that you are not supposed to do exception handling by using try/catch and “traditional/C” methods.
Recently I was reading Amazons AWS iOS SDK and noticed that they have used the old method liberally.
This was a relief for me because I always felt that I need to make sure I catch the exception specially when I am using code written by someone else or binary libraries (I mean things like Google Analytics binaries).
My question is, is there any reason to avoid “traditional” exception handeling” on iOS, or it is just not a tasteful Objective-C practice to do that?

Answer 1

There is every reason to avoid exceptions on iOS.

Exceptions on iOS are explicitly reserved for catastrophic failure that cannot be recovered from. They are not intended to be used to do catch-and-recover type operations.

Important: You should reserve the use of exceptions for programming or
unexpected runtime errors such as out-of-bounds collection access,
attempts to mutate immutable objects, sending an invalid message, and
losing the connection to the window server. You usually take care of
these sorts of errors with exceptions when an application is being
created rather than at runtime.

If you have an existing body of code (such as third-party library)
that uses exceptions to handle error conditions, you may use the code
as-is in your Cocoa application. But you should ensure that any
expected runtime exceptions do not escape from these subsystems and
end up in the caller’s code. For example, a parsing library might use
exceptions internally to indicate problems and enable a quick exit
from a parsing state that could be deeply recursive; however, you
should take care to catch such exceptions at the top level of the
library and translate them into an appropriate return code or state.

This leads to two issues (amongst others):

• you can’t @throw an exception through a frame of system framework code. The behavior is undefined.

• if you design your code to use exceptions, you’ll have a massive impedance mismatch at the border between your code and the system. Not only will this be awkward, it’ll make all future maintenance and refactoring operations more difficult as that border shifts. It will also make it more difficult to integrate with the system.

Note that if the AWS SDK is throwing exceptions through stack frame’s owned by the system frameworks, then it is doing it wrong.