CODEWITHSUNDEEP
objective-ciosexceptiontry-catch
Ali
Ali

Reputation: 19682

Exception Handling in iOS

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?

Upvotes: 7

Views: 6063

Answers (2)

Tatvamasi
Tatvamasi

Reputation: 2547

bbum is spot on. looks like AWS iOS SDK is moving towards NSError based approach for future releases. As of now they provided mechanism to stop Exceptions and work with NSErrors.

#import <AWSiOSSDK/AmazonErrorHandler.h>   
// put this in didFinishLaunching  
[AmazonErrorHandler shouldNotThrowExceptions];

more details here:
https://mobile.awsblog.com/post/Tx2PZV371MJJHUG/How-Not-to-Throw-Exceptions-with-the-AWS-SDK-for-iOS

Upvotes: 2

bbum
bbum

Reputation: 162712

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.

Upvotes: 11

Related Questions