How to return to top level and release memory

[John W. Eaton]

On 29-Aug-2003, Andy Adler <address@hidden> wrote:

| I've been spending some time cleaning up the octave sparse
| matrix code. There were a number of cases where the inverse
| of sparse(zeros(2)) would cause a seg fault.
| 
| When correcting the issue, I decided that it didn't make
| sense to try to continue if the matrix was singular, because:
| 1) the SuperLU libraries don't provide any help, and
| 2) returning a full matrix containing NaN, when the user
| is trying to save memory using sparse probably won't work.
| 
| Currently, when I detect a singular sparse matrix, I throw
| an error, using the following
| 
|  error("sparse: %s", str); octave_throw_bad_alloc ();
| 
| QUESTION:
| 
| Is there a proper way to get out of a deeply nested function,
| (freeing memory on the way), and back to the interpreter?

Throwing an exception will do the right thing if all resources are
allocated in constructors and deallocated in destructors, because in
the process of handling the exception, destructors are called for all
"live" objects (simplified explanation).  But there is no magic way to
handle resources that are allocated/deallocated outside of
constructors/destructors, though the auto_ptr class can help.

We use exceptions for this purpose now when handling interrupts.
Inside the interrupt handler, we set a flag (octave_interrupt_state)
and then throughout the rest of Octave we have the OCTAVE_QUIT macro,
which expands to

  do
    {
      if (octave_interrupt_state)
        {
          octave_interrupt_state = 0;
          octave_throw_interrupt_exception ();
        }
    }
  while (0)

If you have an error, you probaly don't want to throw an interrupt
exception though, and I don't think a bad_alloc exception is really
right.  So we probably need a generic error exception.  In keeping
with the way that the error function works in .m files (automatically
terminating execution of the current function) we should probably
consider making the C++ error function do the same, throwing the new
generic error exception for you.  Then we can eliminate almost all of
the checks of error_state, replacing some with try/catch blocks (which
rethrow the exception, for things like traceback messages).  In a few
places, code will need to be changed (anywhere error is not
immediately followed by return).  But I think it will probably be
worth it.

Comments?

jwe