Thread: Signal and exception handling

Dear Mats,

Originally Posted by matsp

Hang on... A call to abort is usually because the code is "horribly confused" and "can't figure out what to do". Surely the RESULT after "ignoring" such a abort() call would be completely unedefined and unpredictable, and just result in further computation of undefined results? Or do you have some way of "figuring out which parts where affected and thus recover some valuable data"?

Exactly that, as I just wrote in my reply above. The problems only occur with specific data -- which, however, cannot easily be tested for this feature except by using it. This, in turn, creates the signal, which I can then use as a measure for the data, and remove it.

Originally Posted by matsp

I'm just sort of expecting the code that calls abort() to not be able to continue (in a meaningful way) where it came from anyways, even if you override the abort itself.

... and this is why I got the idea with the exception! The catch statement knows exactly what to do and is placed at the correct level to continue in a meaningful way.