Question

I have a few doubts regarding exception handling in iPhone. Here are they:

1. Suppose I have a chain of methods which are being called one after the other, that is, method A calls method B, which in turn calls method C, which calls method D. Which is the best place to put my try-catch block (is it method A or B or C or D or all of them). Also, I need to display an alert to user that an exception has occured and then, I want to log this exception to my server. So, if I am writing my try – catch block in all of this methods and if an exception occurs in method D; then I think the alert will be displayed 4 times and the web service for logging will also be called 4 times (till control reaches to catch block of method A). So, should I just use @throw; in catch block of method B, C and D and write my logic in catch block of method A (top level method) or should I avoid writing try – catch at all in methods B,C and D.

2. I need some sort of error code from the exception (because my web service needs parameters error-code and description). Is it possible to convert an exception to error or will I need to hard-code this code?

3. I had read somewhere about NSSetUncaughtExceptionHandler. And I think, if I can set this handler (in appDidFinishLaunching method of app delegate) and in the handler method, if I show to user some alert and call the web service; then I need not write try – catch block in each of my methods, in each of my classes. Am I right??

4. If an exception has occured and I have written either a try – catch block or NSSetUncaughtExceptionHandler, then will my app continue running or it will not respond to any of the user events. (I am sure it will handle the crash. What I want to know is whether it will hang)

Someone please enlighten me on this EXCEPTION TOPIC.

Answer 1

0) Avoid exceptions in Cocoa. They are generally non-recoverable. You might catch them for your own error reporting, but it’s generally unsafe to assume you can recover from them.

1) If you need to catch, catch it immediately. Don’t write your own throws — instead, convert it to something like an NSError and pass that around. NSError can contain all the information you need to display or send an error code as well as a localized message.

2) You cannot convert an NSException into an NSError (directly) because an NSException does not have all the properties an NSError has – it is a different data representation. For one, an error code is not available. Two, the description is not localized. The best you can do is to create an error code and domain, then use the properties you need from the NSException and store that in an NSError. This could look something like the following:

// error checking omitted
extern NSString* const MONExceptionHandlerDomain;
extern const int MONNSExceptionEncounteredErrorCode;

NSError * NewNSErrorFromException(NSException * exc) {
    NSMutableDictionary * info = [NSMutableDictionary dictionary];
    [info setValue:exc.name forKey:@"MONExceptionName"];
    [info setValue:exc.reason forKey:@"MONExceptionReason"];
    [info setValue:exc.callStackReturnAddresses forKey:@"MONExceptionCallStackReturnAddresses"];
    [info setValue:exc.callStackSymbols forKey:@"MONExceptionCallStackSymbols"];
    [info setValue:exc.userInfo forKey:@"MONExceptionUserInfo"];

    return [[NSError alloc] initWithDomain:MONExceptionHandlerDomain code:MONNSExceptionEncounteredErrorCode userInfo:info];
}

@catch (NSException * exc) {
    NSError * err = NewNSErrorFromException(exc);
    ...
}

If the APIs you use throw exceptions you are expected to catch and recover from (e.g. not truly exceptional cases), then yes, you could catch and attempt to continue. Unfortunately, anybody that writes exceptions in Cocoa with the intent that you will catch them probably does not understand the issues well enough to implement a solid unwind implementation (e.g. even if it produces leaks, it’s not solid).

3) That’s really not the time or place to display an alert. If you install a top level exception handler (via NSSetUncaughtExceptionHandler) – You should simply log a message — then the exception handler will abort. Your app is in an unstable state — continuing is worse than aborting. You may want to send these custom messages home, it’s best to do so at the next launch of your app.

4) In the majority of cases, your app is in an unstable state and you should not continue. But, to actually answer it for those corner cases: “Yes, you can recover and continue when you catch, but you should only attempt to recover and continue when the throwing API states that recovery is supported. If the problem is beyond your control, and the problem is not exceptional (e.g. file not found), and the vendor really expects you to continue, then I would have to assume that they expect you to continue, even though it really isn’t (100% safe).”. Do not attempt to recover/continue from within your top level exception handler (the program will abort after it returns). If you want to be very fancy and present that immediately on OSX, another process would be best. If you are calling through a pure C++ interface, then the unwinding is well defined, and the need to catch is necessary – do continue if it is recoverable. Exceptions in C++ can be recoverable and well defined – they are also used quite extensively (including less than exceptional conditions).

(IMO…) Exceptions in ObjC should not have been introduced, and any method that throws from system or third party libraries should be deprecated. They don’t unwind well, or in a well defined manner. As well, unwinding flows against normal Cocoa program flow. That means that touching any objc object’s memory/relations that was in mutation at the time of the throw and which lies between the throw and the catch is as good as undefined behaviour. Problem is – you have no idea what that memory is (in most cases, and within reasonable maintenance time). C++ exceptions are well defined, and they unwind correctly (e.g. destructors are called) – but trying to continue in an ObjC context is ignoring any consequences of undefined behavior. IMO, they should only exist for ObjC++ (because C++ requires them).

In an ideal world, your ObjC programs and the libraries you use would not use exceptions (at all). Since you use libraries that do throw (including Cocoa), install a top level exception handler only if you need some special information about the error. Where the API mandates that you could expect an exception thrown due to circumstances beyond your control and you are expected to recover, then write a catch but immediately convert that logic to normal program flow (e.g. NSError) – you never need to write your own throw. -[NSArray objectAtIndex: and “object does not respond to selector” are examples of programmer errors – they should not be caught, but the program should be corrected.