Obj-C Exceptions In Gecko

Turns out that Objective-C exceptions and XPCOM don't interact very well.

See bug 163260.

Gecko 1.8

Since there isn't a whole lot of code that's using Cocoa in Gecko 1.8, it might be best to to write macros to wrap any XPCOM entry point that calls cocoa, start to finish. NS_OBJC_EXCEPTION_CATCHER_START and _END, for example.

Another, eviler approach is to override NSException's initWithName:reason:userInfo: method to instead call some sort of assertion, and then return nil. This of course bypasses the entire ObjC exception system, and will horribly, horribly break any code that depends upon actually handling ObjC exceptions. There might still some merit in the idea of posing as NSException, perhaps to override -raise?

Gecko 1.9

Gecko 1.9 has dropped support 10.2. As mentioned in the bug above, 10.3 brought new exception handling support. It's possible that setjmp and longjmp may no longer be used for some parts of the exception system, which now appears to be in the compiler, at least partially. Some parts of the exception handling are still using setjmp/longjmp, obviously, because stack smashing is still occurring. Need to look into exactly what's safe and what's not. We may end up in the same boat as on branch, unfortunately.

As far as I've seen, Apple documents what exceptions can get thrown. We really should just exit the browser with a nonzero exit code when we catch an unhandled ObjC exception. --Cbarrett 15:33, 14 September 2007 (PDT)

setjmp/longjmp not entirely fatal?

It should be noted that as long as the stack is able to be unwound properly once we return to C++, things should be OK. It's still unclear why the crashes are happening in the first place, so perhaps a different NSExceptionHandler mask, using an NSExceptionHandler delegate, or calling NSSetUncaughtExceptionHandler will allow us to handle ObjC exceptions in a more graceful manner.