Too easy to accidentally catch InterruptException()?

[simonster]

Because an InterruptException() is just a normal exception, it's easy to write code that accidentally catches it. In other words:

julia> @everywhere begin
        g() = for i = 1:10000 rand() end
        f(x) = while true
            try
                g()
            catch e
                println("error, continuing")
            end
        end
    end
julia> pmap(f, [1])

leads to a parallel job that cannot be interrupted using interrupt(), continues to run after Julia exits, and can only be stopped by killing julia-release-basic.

[vtjnash]

What would you propose? A DoubleInterruptException, which can only be caught by finally blocks and very special catch statements (so that the REPL loop can still catch it)?

[simonster]

I'm not sure. What you've outlined above would work, but the very special catch statements sound a little frightening. Another possibility might be to attach something to the exception that determines what's allowed to catch it. I haven't looked closely enough at Julia's exception handling to know what's feasible.

As far as other programming languages go, in MATLAB ^C does something that doesn't get caught by catch, but MATLAB also doesn't have a finally construct or an event loop that could be running MATLAB code. In Python it's easy to deal with this using except Exception, since KeyboardInterrupt doesn't inherit from Exception, but Julia doesn't have typed catch clauses, and if isa(err, InterruptException) rethrow(err) end is a little verbose to include in every try/catch block.

[amitmurthy]

interrupt just sends a SIGINT to the processes. Maybe the sigint handler should just terminate the currently running task instead of raising an exception?

[simonster]

I was just thinking about that. Do finally blocks get executed if you terminate a task? Would it be possible to make this approach work at the REPL as well?

[amitmurthy]

The finally blocks may not get executed. On the workers I see that every request is executed using a @schedule - so it should be OK to terminate a runaway task. Not familiar with what happens on the REPL side.

[samoconnor]

#15906 - Uncatchable fatal errors