4
edits
Obj-C Exceptions In Gecko: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
ColinBarrett (talk | contribs) No edit summary |
||
| Line 1: | Line 1: | ||
Turns out that Objective-C exceptions and XPCOM don't interact very well. | Turns out that Objective-C exceptions and XPCOM don't interact very well. | ||
First, see [https://bugzilla.mozilla.org/show_bug.cgi?id=163260 bug 163260]. | |||
= Possible solutions = | |||
== 1.8 branch == | |||
Since there isn't a whole lot of code that's using Cocoa on 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:rerason: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/1.9 == | |||
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. | |||