On 8 Feb 2009, at 06:47, Richard Frith-Macdonald wrote:
Actually, I take it back ... maybe we can recover from an uncaught
exception.
Problem is ... if we are using native exceptions ... by the time the
uncaught handler is called we have unwound the stack entirely and
the program has no way to continue running. But maybe the native
handling code can actually cope with that (or be changed to do that).
I've been doing personality function hacking recently, so I'd be happy
to take a look at this if it's desired.
When the stack is unwound by native ('zero-cost') exceptions, the
unwind library calls the personality function twice for each frame.
The first time is to find the landing pad, the second time is to
perform the unwinding (call cleanup code in each intervening frame and
then continue unwinding).
For a while, I've been pondering adding the Étoilé resumable exception
stuff to the unwinding system. This would call the unhandled
exception function at the top of the stack, before unwinding, and
allow it to either call _Unwind_Resume() or continue, depending on the
exception.
Not sure where the stack pointer and program counter end up if we
are using old-fashioned exceptions.
This is not so difficult. I described it in this paper:
http://www.swan.ac.uk/compsci/research/reports/2008/CSR14-2008.pdf
Basically, you call the uncaught exception handler from [NSException -
raise] and let it to decide whether to unwind the stack or not.
In the general case, there's not much you can do other than pop up a
dialog saying 'Do you want to ignore this exception?' and that's
likely to cause things to break.
So, it is possible, but I'm not sure it's actually a good idea...
David
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev