Re: mapper functions for 3.1

[David Bateman]

John W. Eaton wrote:
> 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
>
>   
Here is an update to the mapper patch implementing your idea..

D.

patch7539.bz2
Description: BZip2 compressed data