setjmp/longjmp vs 754R throw exception

[David Hough 754R work <754r@xxxxxxxxxxx>]

See

http://en.wikipedia.org/wiki/Longjmp

for a brief discussion of setjmp/longjmp.    It seems to raise the
same implementation issues as 754R throw exception:  setjmp has to dump
as much of the local environment as it's going to restore, and put a pointer
to the dump in a place that the corresponding longjmp can access.
longjmp's argument is that pointer, which is uses to restore the environment.
The stack is typically unwound by restoring the stack pointer register.

In contrast, enabling alternate exception handling around a block 
invoking external functions might require similar setup if a language
mandates that the alternate exception handling propagates to invoked
functions.      Then if one of those functions directly or indirectly
throws the corresponding exception, at the point where it might be thrown 
a synchronization might have to occur before invoking a further external 
function or leaving the block.    Whereas longjmp returns to
the setjmp that set up its dump, thrown exceptions might be caught
by other functions in the call stack between the throw and the catch
than the programmer had in mind.

I don't care for either technique - they are hard to get one's mind around -
I would much rather have alternate exception handling that's local to
the function in which the exception arises.

But I don't see how a programming environment that handles programs with
setjmp/longjmp is going to have much more trouble handling 754R throw.
Even "terminate with message" is just an implicit longjmp far enough back to an
environment that knows how to clean up and continue - formerly the 
job control language interpreter, now perhaps a shell.     With threads,
child processes, parent processes, command shells, the idea of "far enough
back" is less definite than it used to be.