MRI 1.8.6 bug - exit is ignored if ensure clause throws exception which is caught by outer rescue

The following code snippet does print “after foo” when using MRI 1.8.6
on Windows Vista, showing that exit is ignored. Any thoughts on whether
this is by design, a known bug, or a new issue? If it’s the latter,
should I open a bug for it?

def foo
begin
begin
begin
exit
rescue
puts “We never reach here”
end
ensure
raise “exception from ensure”
end
rescue
puts “We do reach here, which is unexpected”
end
end

foo
print “after foo”

Thanks,
Shri

On Jan 12, 2009, at 12:31 PM, Shri B. wrote:

The following code snippet does print “after foo” when using MRI
1.8.6 on Windows Vista, showing that exit is ignored. Any thoughts
on whether this is by design, a known bug, or a new issue? If it’s
the latter, should I open a bug for it?

No, this is by design. Kernel#exit raises SystemExit, which the
toplevel rescues and performs the actual exit. If you raise a new
exception in the ensure. the SystemExit exception is never seen by the
toplevel, and thus you don’t get the exit.

This is used in a few places to cause exit to be ignored, or to allow
a library to convert a SystemExit exception into something else
(perhaps an IllegalOperation or something).

  • Evan P.

I believe this is by design. Exit throws an exception (SystemExit). The
exception is not rescued by a default rescue clause because it doesn’t
derive from StandardError. Thus the raise in ensure gets called and it
raises RuntimeError which gets caught in the outer rescue because
RuntimeError <: StandardError.

Tomas

From: Shri B. [mailto:[email protected]]
Sent: Monday, January 12, 2009 12:32 PM
To: [email protected]; [email protected]
Subject: [ruby-core:21289] MRI 1.8.6 bug - exit is ignored if ensure
clause throws exception which is caught by outer rescue

The following code snippet does print “after foo” when using MRI 1.8.6
on Windows Vista, showing that exit is ignored. Any thoughts on whether
this is by design, a known bug, or a new issue? If it’s the latter,
should I open a bug for it?

def foo
begin
begin
begin
exit
rescue
puts “We never reach here”
end
ensure
raise “exception from ensure”
end
rescue
puts “We do reach here, which is unexpected”
end
end

foo
print “after foo”

Thanks,
Shri

OK, I have added a RSpec test, and have already tagged it as an
IronRuby bug.

For reference, .NET allows the equivalent ThreadAbortException to be
caught, but automatically rethrows it at the end of the catch/rescue
block. The programmer is required to take a separate action (calling
Thread.ResetAborthttp://msdn.microsoft.com/en-us/library/system.threading.thread.resetabort.aspx)
to complete cancel the abort operation. This prevents situations where
one component triggers the abort, and another cancels it unintentially.
In theory, you should always do “rescue SomeSpecificExceptionType”, but
a lot of people do use just “rescue”.

From: Evan P. [mailto:[email protected]]
Sent: Monday, January 12, 2009 1:01 PM
To: [email protected]
Subject: [ruby-core:21290] Re: MRI 1.8.6 bug - exit is ignored if ensure
clause throws exception which is caught by outer rescue

On Jan 12, 2009, at 12:31 PM, Shri B. wrote:

The following code snippet does print “after foo” when using MRI 1.8.6
on Windows Vista, showing that exit is ignored. Any thoughts on whether
this is by design, a known bug, or a new issue? If it’s the latter,
should I open a bug for it?

No, this is by design. Kernel#exit raises SystemExit, which the toplevel
rescues and performs the actual exit. If you raise a new exception in
the ensure. the SystemExit exception is never seen by the toplevel, and
thus you don’t get the exit.

This is used in a few places to cause exit to be ignored, or to allow a
library to convert a SystemExit exception into something else (perhaps
an IllegalOperation or something).

  • Evan P.

def foo
begin
begin
begin
exit
rescue
puts “We never reach here”
end
ensure
raise “exception from ensure”
end
rescue
puts “We do reach here, which is unexpected”
end
end

foo
print “after foo”

Thanks,
Shri

I was assuming that exit and Thread.current.kill do the same thing, but
Tomas pointed out that they are different. Would you expect that “after
foo” would get printed even if you replace exit with
Thread.current.kill?

Thanks,
Shri

From: [email protected]
[mailto:[email protected]] On Behalf Of Shri B.
Sent: Monday, January 12, 2009 2:10 PM
To: [email protected]; [email protected]
Subject: Re: [Ironruby-core] [ruby-core:21290] Re: MRI 1.8.6 bug - exit
is ignored if ensure clause throws exception which is caught by outer
rescue

OK, I have added a RSpec test, and have already tagged it as an
IronRuby bug.

For reference, .NET allows the equivalent ThreadAbortException to be
caught, but automatically rethrows it at the end of the catch/rescue
block. The programmer is required to take a separate action (calling
Thread.ResetAborthttp://msdn.microsoft.com/en-us/library/system.threading.thread.resetabort.aspx)
to complete cancel the abort operation. This prevents situations where
one component triggers the abort, and another cancels it unintentially.
In theory, you should always do “rescue SomeSpecificExceptionType”, but
a lot of people do use just “rescue”.

From: Evan P. [mailto:[email protected]]
Sent: Monday, January 12, 2009 1:01 PM
To: [email protected]
Subject: [ruby-core:21290] Re: MRI 1.8.6 bug - exit is ignored if ensure
clause throws exception which is caught by outer rescue

On Jan 12, 2009, at 12:31 PM, Shri B. wrote:

The following code snippet does print “after foo” when using MRI 1.8.6
on Windows Vista, showing that exit is ignored. Any thoughts on whether
this is by design, a known bug, or a new issue? If it’s the latter,
should I open a bug for it?

No, this is by design. Kernel#exit raises SystemExit, which the toplevel
rescues and performs the actual exit. If you raise a new exception in
the ensure. the SystemExit exception is never seen by the toplevel, and
thus you don’t get the exit.

This is used in a few places to cause exit to be ignored, or to allow a
library to convert a SystemExit exception into something else (perhaps
an IllegalOperation or something).

  • Evan P.

def foo
begin
begin
begin
exit
rescue
puts “We never reach here”
end
ensure
raise “exception from ensure”
end
rescue
puts “We do reach here, which is unexpected”
end
end

foo
print “after foo”

Thanks,
Shri