Using C++ exceptions in liboctave (was: Re: mapper functions for 3.1)

[John W. Eaton]

On 14-Feb-2008, John W. Eaton wrote:

| Also, another possible problem is that we have code like this:
| 
|   [...]
| 
| in which we currently continue on after a call to the error_handler.
| In most cases (including the one above), I think that we are OK to
| just throw an execption and bypass any cleanup, but I can't be sure
| without looking at all the cases individually.
| 
| If I am going to check all of these individually, then maybe we should
| go a step further at the same time and replace the use of
| f77_exception_encountered with a C++ exception.  I think all of these
| cases are internal errors from which we can't recover, so an exception
| would be simpler as there would be no need to check after every call
| to F77_XFCN and we could just handle the exception at a higher level.
| If necessary, we can use try/catch for any of these
| f77_exception_encountered cases that need to be handled locally.

After looking at it a bit more, f77_exception_encountered should only
be set by the XSTOPX function, which should only be called by XERBLA,
and it should always be a fatal error (typically incorrect parameter
values passed in to a BLAS or LAPACK subroutine) so there is not much
point in continuing past an error like that as it represents a coding
error in Octave.

With the changes I posted earlier, I think it is safe to simply remove
these checks, since if there is an exception, they will no longer be
reached anyway.  The reason is that if XSTOPX is called, it sets
f77_exception_encountered and then longjmps back to the location of
the closest F77_XFCN call on the stack.  At that point, the value of
f77_exception_encountered is checked, and a call is made to the
liboctave error handler.  With current_liboctave_error_handler set to
the new lo_error_handler function that calls error and then throws an
exception, we will then get back to the catch block in pt-stmt.cc,
then we will resume the Octave error handling with error_state.

The only potential problem I see is that a coding error in liboctave
that results in a call to XSTOPX will cause trouble for someone using
liboctave if they haven't set an error handler that throws an
exception.  I'm not sure whether we should try to fix that as any call
to XSTOPX represents a bug in liboctave.  The reason we try to handle
it for Octave is that it is unfriendly to have an error like this
simply exit Octave.  OTOH, that's precisely what happens on systems
that don't allow us to override XERBLA...

In any case, I've removed all the checks on f77_exception_encountered
in the Octave sources except in the F77_XFCN macro.

I also checked the Octave Forge sources, and I think in most cases
f77_exception_encountered is probably not being used correctly, as it
is checked after some functions that I don't think can call XSTOPX, or
execution continues beyond the check.  Given that the
f77_exception_encountered variable will remain, it is harmless to
leave this code as it is at least for now, but I think think these
checks should be removed eventually.

One final note about the earlier changes I made.  Code that calls the
liboctave error handler and expects to continue will now work a bit
differently.  Instead of calling the error handler multiple times,
only the first call will happen, then an exception will be thrown
which will skip the subsequent calls and return execution to the
catch clause in pt-stmt.cc.  I think we have some code like this

  error ("first line of error message");
  error ("second line of error message");
  return retval;

in Octave itself, but I'm not sure whether we have the equivalent in
liboctave (using current_liboctave_error_handler instead of calling
error directly).  A quick check didn't turn up any, but I didn't
analyze every call in detail.

jwe