[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Exception handling
David Hough wrote:
Otherwise, what are the new issues with 754R throw excepName are that
aren't already faced in dealing with setjmp/longjmp and their ilk?
The difference is that longjmp() is synchronous -- the state is
well-defined, as was the state at the matching setjmp(). At the
instruction level these are ordinary subroutine invocations.
Vincent LefÃ?vre wrote:
Also note that this isn't specific to FP exceptions.
Yes, but are there standards that define what shall/should be
available for dealing with those exceptions? Note that explicit
signal, Throw or longjmp are not the issue here.
... All the exception handler needs to
do is to set a flag. Such a flag would just be checked at some
control points.
Ok, we're assuming that the run-time provides context-independent
access to a thread-static area (e.g. via dedicated register, or
some other means such as detecting interruptions in the middle of
a prologue or epilogue). Without barriers the flag might however
be set in a different block from the logical exception. That's ok
for terminate-with-message, but problematic otherwise.
I note that compilers do insert eye-catchers near prologues and
epilogues, and generate code in a way that makes them unambiguous,
so the general mechanism of recovering from asynchronous interrupts,
including machine checks, is often present. In most cases however
this recovery is insufficient to identify THE responsible block,
though they are capable of restoring some consistent state and report
on that, which again fits with "terminate-with-message" but not with
a more general throw-catch mechanism.
Michel.
Sent: 2007-06-07 16:12:09 UTC