[jcizzle]

Yes, but that is just the default behavior, does this not work?

    NSSetUncaughtExceptionHandler({exception in
       print("\(exception)")
       exit(1)
    });

[mikeash]

Nope. These exceptions aren't actually uncaught, they're caught by an exception handler in the event loop. NSSetUncaughtExceptionHandler only catches exceptions thrown when there's no handler in place at all, all the way up to the top of the current thread's stack. In practice, this means it really only works for exceptions thrown on secondary threads.

Even if you could modify the behavior, having the default work this way would still be terrible.

[jcizzle]

Interesting. Just tried another approach, and you can get the behavior by overriding reportException: in a custom NSApplication subclass.

edit: Also I'm not suggesting to just naively exit(1). edit2: Strangely, exception generating code in [[NSOperationQueue mainQueue] addOperationWithBlock:] does actually hit the NSUncaughtExceptionHandler, which was surprising to me.

[mikeash]

The mainQueue thing is because the catch-all exception handler is in the event loop, not the runloop. So if you throw during event handling (mouse down, key down) you'll hit it, but if it's something else (GCD, timers) you won't. It's extremely weird.

Good call about reportException:. Although I personally prefer to just avoid NSAssert. The good old C assert() gets the job done well for me.

[jcizzle]

Good to note, I must have logically mapped addOperationWithBlock: to a typical NSResponder event in my head, but what you're saying makes more sense.