Why is raising an NSException not bringing down my

Question

The Problem

I'm writing a Cocoa application and I want to raise exceptions that will crash the application noisily.

I have the following lines in my application delegate:

[NSException raise:NSInternalInconsistencyException format:@"This should crash the application."];
abort();

The problem is, they don't bring down the application - the message is just logged to the console and the app carries on it's merry way.

As I understand it, the whole point of exceptions is that they're fired under exceptional circumstances. In these circumstances, I want the application to quit in an obvious way. And this doesn't happen.

What I've tried

I've tried:

-(void)applicationDidFinishLaunching:(NSNotification *)note
    // ...
    [self performSelectorOnMainThread:@selector(crash) withObject:nil waitUntilDone:YES];
}

-(void)crash {
    [NSException raise:NSInternalInconsistencyException format:@"This should crash the application."];
    abort();
}

which doesn't work and

-(void)applicationDidFinishLaunching:(NSNotification *)note
    // ...
    [self performSelectorInBackground:@selector(crash) withObject:nil];
}

-(void)crash {
    [NSException raise:NSInternalInconsistencyException format:@"This should crash the application."];
    abort();
}

which, rather confusingly, works as expected.

What's going on? What am I doing wrong?

Answer 1

Maybe you can use NSSetUncaughtExceptionHandler, or create a category on NSApplication that overrides -reportException:, as suggested at http://www.cocoadev.com/index.pl?StackTraces

Answer 2

I've posted this question and answer as I wish someone had told me this, oh, about a year ago:

Exceptions thrown on the main thread are caught by NSApplication.

I skim read the docs on NSException end to end, with no mention of this that I can recall. The only reason I know this is because of the fantastic Cocoa Dev:

http://www.cocoadev.com/index.pl?ExceptionHandling

The Solution. I guess.

I've got a daemon with no UI that almost entirely runs on the main thread. I'll have to transfer the whole app to run background threads, unless someone else can suggest a way of stopping NSApplication catching just the exceptions I throw. I'm pretty sure that's not possible.

Answer 3

I'm trying to understand this properly: Why does the following category method on NSApplication lead to an infinite loop? In that infinite loop, "An uncaught exception was raised" is logged out infinitely many times:

- (void)reportException:(NSException *)anException
{
    // handle the exception properly
    (*NSGetUncaughtExceptionHandler())(anException);
}

For testing (and understanding purposes), this is the only thing I do, i.e. just create the above category method. (According to the instructions in http://www.cocoadev.com/index.pl?StackTraces)

Why would this cause an infinite loop? It's not consistent with what the default uncaught exception handler method should do, i.e. just log the exception and exit the program. (See http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Exceptions/Concepts/UncaughtExceptions.html#//apple_ref/doc/uid/20000056-BAJDDGGD)

Could it be that the default uncaught exception handler is actually throwing the exception again, leading to this infinite loop?

Note: I know it's silly to create only this category method. The purpose of this is to gain a better understanding.

UPDATE: Never mind, I think i get this now. Here is my take. By default, as we know, NSApplication's reportException: method logs the exception. But, according to the docs, the default uncaught exception handler logs the exception and exists the program. However, this should be worded like this in the docs to be more precise: The default uncaught exception handler calls NSApplication's reportException: method (in order to log it, which the method's default implementation indeed does), and then exists the program. So now it should be clear why calling the default uncaught exception handler inside an overridden reportException: causes an infinite loop: The former calls the latter.

Answer 4

UPDATE - Nov 16, 2010: There are some issues with this answer when exceptions are thrown inside IBAction methods. See this answer instead:

How can I stop HIToolbox from catching my exceptions?

---

This expands on David Gelhar's answer, and the link he provided. Below is how I did it by overriding NSApplication's -reportException: method. First, create an ExceptionHandling Category for NSApplication (FYI, you should add a 2-3 letter acronym before "ExceptionHandling" to reduce the risk of name clashing):

NSApplication+ExceptionHandling.h

#import <Cocoa/Cocoa.h>

@interface NSApplication (ExceptionHandling)

- (void)reportException:(NSException *)anException;

@end

NSApplication+ExceptionHandling.m

#import "NSApplication+ExceptionHandling.h"

@implementation NSApplication (ExceptionHandling)

- (void)reportException:(NSException *)anException
{
    (*NSGetUncaughtExceptionHandler())(anException);
}

@end

---

Second, inside NSApplication's delegate, I did the following:

AppDelegate.m

void exceptionHandler(NSException *anException)
{
    NSLog(@"%@", [anException reason]);
    NSLog(@"%@", [anException userInfo]);

    [NSApp terminate:nil];  // you can call exit() instead if desired
}

- (void)applicationWillFinishLaunching:(NSNotification *)aNotification
{
    NSSetUncaughtExceptionHandler(&exceptionHandler);

    // additional code...

    // NOTE: See the "UPDATE" at the end of this post regarding a possible glitch here...
}

Rather than use NSApp's terminate:, you can call exit() instead. terminate: is more Cocoa-kosher, though you may want to skip your applicationShouldTerminate: code in the event an exception was thrown and simply hard-crash with exit():

#import "sysexits.h"

// ...

exit(EX_SOFTWARE);

---

Whenever an exception is thrown, on the main thread, and it's not caught and destroyed, your custom uncaught exception handler will now be called instead of NSApplication's. This allows you to crash your application, among other things.

---

UPDATE:

There appears to be a small glitch in the above code. Your custom exception handler won't "kick in" and work until after NSApplication has finished calling all of its delegate methods. This means that if you do some setup-code inside applicationWillFinishLaunching: or applicationDidFinishLaunching: or awakeFromNib:, the default NSApplication exception handler appears to be in-play until after it's fully initialized.

What that means is if you do this:

- (void)applicationWillFinishLaunching:(NSNotification *)aNotification
{
        NSSetUncaughtExceptionHandler(&exceptionHandler);

        MyClass *myClass = [[MyClass alloc] init];   // throws an exception during init...
}

Your exceptionHandler won't get the exception. NSApplication will, and it'll just log it.

To fix this, simply put any initialization code inside a @try/@catch/@finally block and you can call your custom exceptionHandler:

- (void)applicationWillFinishLaunching:(NSNotification *)aNotification
{
    NSSetUncaughtExceptionHandler(&exceptionHandler);

    @try
    {
        MyClass *myClass = [[MyClass alloc] init];   // throws an exception during init...
    }
    @catch (NSException * e)
    {
        exceptionHandler(e);
    }
    @finally
    {
        // cleanup code...
    }
}

Now your exceptionHandler() gets the exception and can handle it accordingly. After NSApplication has finished calling all delegate methods, the NSApplication+ExceptionHandling.h Category kicks in, calling exceptionHandler() through its custom -reportException: method. At this point you don't have to worry about @try/@catch/@finally when you want exceptions to raise to your Uncaught Exception Handler.

I'm a little baffled by what is causing this. Probably something behind-the-scenes in the API. It occurs even when I subclass NSApplication, rather than adding a category. There may be other caveats attached to this as well.

Answer 5

There turns out to be a very simple solution:

[[NSUserDefaults standardUserDefaults] registerDefaults:@{ @"NSApplicationCrashOnExceptions": @YES }];

It does not crash your app if you use @try ... @catch.

I can't begin to imagine why this isn't the default.