Re: Ctrl-C & error handling

[Jaroslav Hajek]

On Sun, Mar 29, 2009 at 9:49 PM, John W. Eaton <address@hidden> wrote:
> On 29-Mar-2009, Jaroslav Hajek wrote:
>
> | On Sun, Mar 29, 2009 at 4:09 PM, Jaroslav Hajek <address@hidden> wrote:
> | > On Sun, Mar 29, 2009 at 3:39 PM, John W. Eaton <address@hidden> wrote:
> | >> On 29-Mar-2009, Jaroslav Hajek wrote:
> | >>
> | >> | is there any possibility for an m-function to implement a custom
> | >> | cleanup when Ctrl-C is detected? unwind_protect does not seem to catch
> | >> | Ctrl-C.
> | >> | The problem is that if a function manipulates system resources in a
> | >> | non-trivial manner, like parcellfun from the general package, it is
> | >> | not easy to manually clean up (parcellfun interrupted by Ctrl-C leaves
> | >> | hanging processes in the memory).
> | >>
> | >> The unwind-protect mechanism is intended to handle interrupts, so I
> | >> think it is a bug if somehow Ctrl-C jumps back to the top level
> | >> without evaluating the cleanup blocks.
> | >>
> | >
> | > OK, I hoped so. So the following simplistic script does not work:
> | >
> | > unwind_protect
> | >  pause(10);
> | > unwind_protect_cleanup
> | >  disp ("break");
> | > end_unwind_protect
> | >
> | > when I run it and press Ctrl-C, nothing is displayed.
> | >
> | >
> |
> | I pushed the following change:
> | http://hg.savannah.gnu.org/hgweb/octave/rev/eabdfcc977f1
> |
> | I'm not sure it is the right thing, but it seems to do what I want.
>
> I'll have to think about it, but it seems likely that your change is
> correct.  Thanks for looking at it.

OK, please alert me if it's going to be more complicated. With this
change, parcellfun now seems correctly breakable (no hangup
processes). One thing that surprises me, is that when I break
parcellfun with Ctrl-C, the catch blocks of the subprocesses seem to
get executed. This does not happen with a test function, though. Hmm.
I expect it's one of them phenomena. (Terry Pratchett)


> | Should try/catch catch interrupts, too?
>
> I don't think of interrupts as errors/exceptions, so I don't think it
> should.  Also, I don't think Matlab's try/catch does, so we might
> generate compatibility complaints if we changed Octave's try/catch
> behavior wrt interrupts.
>

I don't think there's much to follow in Matlab. For instance, when I
try the above script in Matlab 2007a and break it, I get:
>> tt
Error in ==> tt at 3
  pause(10);

So it seems that Matlab does regard interrupt as error in some sense,
only fails to catch it. Since it apparently doesn't do anything
intelligent, I am fairly convinced that we would get no complaints if
Octave did something smarter.

cheers

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz