sparse matrices and error handling

[John W. Eaton]

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

| Recent changes in Octave have changed the way critical errors are handled.
| It use to be that when code encountered an unrecoverable error, it could
| use jump_to_top_level to return to the octave prompt.  That is no longer
| the case, so sparse matrix error handling will have to be revisited.  

OK.  I'm still planning to integrate the sparse matrix code with
Octave, but I haven't really looked at it, so I don't know how much
work that will be or when it will happen, but this project is near the
top of my list.

| I'll see to what extent I can turn it into error propogation code.  I may
| have to use setjmp/longjmp to catch errors from deep within superlu.  Andy,
| do you have any opinions on how this should be done?  I'm thinking of
| changing the internal functions so that instead of returning matrices, they
| take a matrix reference as a parameter and modify that, and return an
| error flag.

If you can't avoid longjmp, then you should set it up as a call to
foreign code and use the octave_jump_to_enclosing_context when you
need to bail out.  There are macros to do this in quit.h for
non-fortran code.  I'm currently using them around the call to
readline for user input.

| John, does error() now throw an exception so that oct-files no longer
| have to check for error_state after every operation?  This is a
| rhetorical question, since I see from the code that error_state is
| alive and well.

Right, as you discovered, error still uses the same bad "call and check
error status everywhere" style of exception handling.  This should
change, but I think we need to come up with a reasonable migration
strategy if we can, so that existing code that checks error_state will
continue to work along with code that uses exceptions.

The other thing related to exception handling that still needs to
be fixed is unwind_protect, but i'm not sure that a good migration
strategy is needed for that.  I'd guess that there isn't too much code
that uses it (apart from the Octave distribution, which will be
updated when any change is made).

| This business of propogating error_state is why I 
| was looking at C++ exception handling a couple of years ago.  Between 
| that and better memory recover, I'm almost convinced that C++ exceptions 
| are a good idea.

What would it take to more than almost convince you?

| Too bad they aren't integrated with posix signal 
| handling in any meaningful way 8-(

Yes, that would be helpful.

jwe