Re: more on exceptions; new handler

[John W. Eaton]

On 15-Nov-2002, Paul Kienzle <address@hidden> wrote:

| Okay, I played with exceptions some more.  The attached except.cc does
| work rather than sleep each iteration so you can see that pressing
| Ctrl-C does not actually get you to the next iteration any faster.  Sleep
| returns immediately after a signal even if the allotted time has not
| passed.

OK.

| I tried throwing an exception directly from the signal handler but that
| didn't work.  So it looks like we will indeed have to use this screwy
| system of wrapping any computationally intensive code (even C++ code!!)
| in the setjmp/longjmp equivalent of try/catch.  How about a START_OP
| macro to push a new jump buffer, and END_OP to pop it.

Sure, I think that's what I already have in the current F77_XFCN macro
in Octave itself.

| No resource
| allocation is allowed between START_OP and END_OP otherwise we would
| need to parameterize the START_OP with clean up code.

Right, that's the current assumption -- any allocations that happen
inside an F77_XFCN call (in Octave) are handled in some other way.
Currently, they can only happen in C++ code called from the Fortran,
and those are protected.  But we could have some way to specify a
clean up function too.

| I still don't know what happens if you throw an exception from a callback
| through Fortran code which was not compiled with -fexceptions.

You crash with a call to abort(), I think.  That's what happened for my
bad_alloc throws before I protected them with a catch block in the
callbacks.

So, give me an hour or so to update the simple except.cc to
demonstrate all these features in a simpler form than all of Octave.
I'll post to the list when I have it working.

jwe