Re: mapper functions for 3.1

[John W. Eaton]

On 14-Feb-2008, David Bateman wrote:

| In fact it seems to me that it wouldn't be hard to add a c++ exception
| in this case, or in fact in the general liboctave case. For the mapper
| functions only the F77_XFCN can cause an error, and if we add an
| exception in this case, then with the corresponding catch in
| pt-stmt.cc(tree_statement_list::eval) this would be fairly trivial. In
| fact we could modify the lo-error.cc (set_liboctave_error_handler)
| function so that it wrapped the function that was passed in another
| function that also threw an exception. Is it really that simple? Am I
| missing something?
| 
| In any case the proposed change will be likely to slow the mapper
| function down as the check on error_state now needs to call an
| additional function, whereas the exception idea will speed if up as we
| will not have to check the error_state for each element in the loop.

That could be avoided by just allowing direct access to the variable.

But anyway, throwing an exception is probably best, and as you say, if
we just set liboctave_error_handler to a function that prints the
message and throws an exception instead of setting it to the error
function defined in /src/error.cc, then I think that will do most of
what we need with minimal impact.  We'll need to catch the exception
and then call Octave's error function again (so that error_state is
set properly).  We'll also need to do whatever is necessary to handle
exceptions that are thrown in callback functions that are executed by
non-C++ code (for example, the user-defined functions used by fsolve,
quad, lsode, daspk, etc.).  I'm not sure, but I think that means
catching them in the callback and setting a global variable indicating
an exception has occurred, calling longjmp, then rethrowing the
exception.  This is similar to what is supposed to happen for
allocation exceptions in callbacks, so I think it can be handled the
same, and will only require changing the macros in f77-fcn.h and
quit.h in the libcruft/misc directory, possibly with the addition of a
helper function or two.  Would you like for me to work on this part?

jwe