“Signals and exceptions don’t mix well, and should be considered seperately. While you can define an exception-based wrapper for signals, such code is not portable, because C++ does not guarantee that a signal-handling function is able to interact with any other part of a program. Creating a signal handler that throws an exception, for example, is undefined behavior in Standard C++.”

Thankfully this is not so true anymore. I can attest from experience that Solaris and HPUX have allowed you to do this for a while, but GNU/Linux has always been a problem child. Thankfully a lot of effort has recently been put into GCC, allowing you to trigger an exception from within syncronous signals, thus bridging the gap, sadly however the x86 platform does not seem to be one of the architectures fixed, and the gcc-java compiler only seems to be able to do this by rewriting the stack frame from within the signal.

If you are using GCC, you cannot expect to throw exceptions through arbitrary C library functions like raise(). If you don’t do this and want to handle asynchronous exceptions, you need at least -fnon-call-exceptions in all code that might raise synchronous signals and/or -fasynchronous-unwind-tables in all code that might be interrupted by asynchronous signals you want to throw from (obviously you have to make sure that you don’t throw while the asynchronous signal interrupted some function without exception support).

[UPDATE]

So far using -fnon-call-exceptions with gcc3.4 on x86 I have managed to allow a signal to throw an exception, but then it ends up in the designated terminate and atexit code. Whoopdy do! But catching that exception in the context that generated the signal is still out of my reach. This is obviously because the signal is happening on a different stack. If you read the default behavior for a throw() with no catch, then the issue seems clearer.

[UPDATE] Time to give up on this – even -fsignaling-nans has no effect. I have fixed the major problem in that some of my test cases were loosing the plot every day and logging an infinite number of execptions to a finite harddrive. So its back to the parser.