Hacker News new | ask | show | jobs
by mikeash 3757 days ago
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.
1 comments
jcizzle 3757 days ago
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.

link
mikeash 3757 days ago
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.

link
jcizzle 3757 days ago
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.
link