matlab equivalent of unwind_protect in R2008a

[John W. Eaton]

On 17-Mar-2008, David Bateman wrote:

| Seems matlab finally introduce the equivalent of unwind_protect in
| R2008a with the onCleanup function. The example they give is like
| 
| function changeDirectorySafely(fileName)
| currentDir = pwd;
| c = onCleanup(@()cd(currentDir));
| 
| functionThatMayError;
| end % c executes cd(currentDir) here
| 
| and they state that the cd(currentDir) is executed even if the function
| creates an error. This is implemented in the new object class
| definitions, where the destructors for "c" are always called when c is
| destroyed. The stupid thing about this is that
| 
| function changeDirectorySafely(fileName)
| currentDir = pwd;
| onCleanup(@()cd(currentDir));
| 
| functionThatMayError;
| end % c executes cd(currentDir) here
| 
| will not do the same as the above as "ans" is destroyed immediately and
| so the cleanup code is executed early.. I don't believe there are
| destructors in the Octave object classes which are compatible with
| Matlab v7.5 and earlier, and so we can't yet do it this way. However,
| with a bit of manipulation of the unwind_protect stack we can get the
| same behavior.
| 
| We have to be careful of cases like
| 
| function changeDirectorySafely(fileName, cleanup)
| currentDir = pwd;
| if (cleanup)
|   c = onCleanup(@()cd(currentDir));
| end
| 
| functionThatMayError;
| end % c executes cd(currentDir) here
| 
| as the cleanup will only happen if the "cleanup" variable is true, and
| this is no longer the same structure as a traditional unwind_protect
| block. So we can't use directly the unwind_protect code in the parser.
| However, something like the attached seems to implement the same
| behavior.

| Is the attached
| function useful? Do you John prefer to implement the classdef code with
| the destructors and really do this function in a matlab compatible manner?

Since this function was only recently introduced and we would only be
adding it to the development branch anyway, it it important enough to
add now?  I think I'd prefer to wait and do it with a class
destructor.  OTOH, you've already done the work to implement a
temporary solution.  If you feel strongly that this code should be
included, then I'll add it.

One thing I noticed when looking at this function was that it might be
a bit fragile since it depends on looking at the tag that
octave_user_function::do_multi_index_op inserts into the
unwind_protect stack, and that it would mysteriously fail if someone
decided to change the label.  Then I noticed that the
octave_user_function::do_multi_index_op function adds 5 functions to
the unwind_protect stack (or up to 7 for recursive calls) and that
maybe it would be better to group these in some way and add a single
cleanup function to the unwind_protect stack.  If we did that, then
onCleanup could just look up the current function and call a method
defined in the octave_user_function class that adds the function to a
list of user-defined cleanup functions.

| The only thing it won't do the same is something like
| 
| function changeDirectorySafely(fileName)
| currentDir = pwd;
| c = onCleanup(@()cd(currentDir));
| 
| functionThatMayError;
| 
| clear c; % c executes cd(currentDir) here
| 
| functionThatWontError;
| end
| 
| as the cleanup occurs when c is cleared. Do we care?

To do this without class destructors, I guess we could come up with
some way to attach a function to symbols in the symbol table and have
those functions called when the symbol is cleared.  But then that
sounds a lot like a destructor...

BTW, onCleanup?  Ugh, is this kind of naming the start of a trend?

Anyway, if you really feel that this function should be added now as a
temporary fix, let me know.

jwe