Confirm, emeritus
1,680
edits
Changes
→trunk/1.9
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?
== trunk/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.
== 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.
