7

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?

Cœur
  • 37,241
  • 25
  • 195
  • 267
Ali
  • 18,665
  • 21
  • 103
  • 138
  • 4
    Well, try/catch is not a 'traditional C' method of handling errors. – Perception Jul 21 '11 at 21:14
  • 1
    The traditional C method of handling error is to return `NULL` or -1 to indicate error and set the global `errno`. Another common technique is to return the error code directly, with one possible error being SUCCESS or NO_ERROR or the like. C has no direct language support for exceptions. `setjmp` and `longjmp` provide tools to implement them, but it's not a language feature like in C++. – Rob Napier Jul 24 '11 at 21:16

2 Answers2

11

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.

bbum
  • 162,346
  • 23
  • 271
  • 359
  • as far as I can see AWS SDK is using try/catch to deal with problems like network connectivity problems or disk access issues or things of this nature. – Ali Jul 21 '11 at 21:23
  • 1
    OK, but are they recoverable errors? If so, they should not be using exceptions. If they are unrecoverable exceptions used to exit the app (preferably with a crash report), that is fine. – bbum Jul 21 '11 at 21:42
  • thanks, but let's say I am sending an object (which I have no control over it, it's a system or a third party API) and it happens that some times it throws an exception (for whatever reason), then how should I avoid crashing? – Ali Jul 21 '11 at 22:18
  • 1
    You have to catch the exception at the boundary between your code and the 3rd party API, then process it accordingly. If that library passes an exception through system code that it calls directly, then that library *is broken*. – bbum Jul 21 '11 at 23:17
  • If I understand the following link correctly, there's a lot of FUD around iOS exceptions. http://club15cc.com/code/objective-c/dispelling-nsexception-myths-in-ios-can-we-use-try-catch-finally – occulus May 06 '13 at 07:09
  • But also be sure to read the comments to blog post, they're quite enlightening too. – occulus May 06 '13 at 07:15
  • @occulus while technically deep, that blog post's conclusion is wrong. It misses that exceptions thrown over **any frame of framework code** is undefined behavior and it advocates a pattern of implementation that is an impedance mismatch with the system. Following that guidance will yield code that is more fragile and less maintainable than following Apple's documented standards. – bbum May 06 '13 at 13:42
  • I've blogged my comments and more detailed info on this blog post a while ago: http://orangejuiceliberationfront.com/why-cocoa-programmers-cant-have-nice-things/ Might be useful for not just a technical, but a practical view of why using exceptions in ObjC isn't very useful right now. – uliwitness Sep 04 '13 at 15:45
2

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

Tatvamasi
  • 2,537
  • 19
  • 14