Project

General

Profile

Bug #2048

Thread#raise: Handling of Current Exception

Added by runpaint (Run Paint Run Run) over 10 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Normal
Target version:
ruby -v:
ruby 1.9.2dev (2009-09-03 trunk 24741) [i686-linux]
Backport:
[ruby-core:25367]

Description

=begin
$ cat /tmp/thread.rb
t = Thread.new do
begin
1/0
rescue ZeroDivisionError
sleep 3
end
end

Thread.pass while t.status and t.status != "sleep"
t.raise
t.value
t.kill

$ ruby -v /tmp/thread.rb
ruby 1.9.2dev (2009-09-03 trunk 24741) [i686-linux]
/tmp/thread.rb:5:in sleep': unhandled exception
from /tmp/thread.rb:5:in
rescue in block in '
from /tmp/thread.rb:2:in `block in '

$ ruby8 -v /tmp/thread.rb
ruby 1.8.8dev (2009-09-04) [i686-linux]
/tmp/thread.rb:3:in /': divided by 0 (ZeroDivisionError)
from /tmp/thread.rb:11:in
value'
from /tmp/thread.rb:11

On 1.8 Thread#raise re-raises the current exception; on 1.9 it doesn't.
=end

History

#1

Updated by yugui (Yuki Sonoda) over 10 years ago

  • Status changed from Open to Assigned
  • Assignee set to ko1 (Koichi Sasada)
  • Priority changed from Normal to 5
  • Target version set to 1.9.2

=begin

=end

#2

Updated by marcandre (Marc-Andre Lafortune) over 10 years ago

  • Status changed from Assigned to Closed
  • % Done changed from 0 to 100

=begin
Applied in changeset r25278.
=end

#3

Updated by nobu (Nobuyoshi Nakada) over 10 years ago

  • Status changed from Closed to Open

=begin
I think r25278 is wrong.
The point should be that rescue clause restores its originating exception in 1.8 but it doesn't in 1.9.
Still I'm not sure if this is intentional change.
=end

#4

Updated by nobu (Nobuyoshi Nakada) over 10 years ago

  • Status changed from Open to Closed

=begin
Sorry, it comes feeling right.
And seems rdoc doesn't mention the no argument case.
=end

#5

Updated by naruse (Yui NARUSE) over 10 years ago

=begin
If you change interpreter or VM of Ruby, please get an approval by matz in ruby-core/Redmine (or ruby-dev).
Sorry for this was an implicit rule,
but it is important to let core developers know such critical changes.

Anyway, can you fold your commit logs by about 80 columns?
=end

#6

Updated by matz (Yukihiro Matsumoto) over 10 years ago

=begin
Hi,

This one has been filed in my spam folder. Sorry.

In message "Re: [ruby-core:25367] [Bug #2048] Thread#raise: Handling of Current Exception"
on Sat, 5 Sep 2009 01:59:16 +0900, Run Paint Run Run redmine@ruby-lang.org writes:
|
|Bug #2048: Thread#raise: Handling of Current Exception
|http://redmine.ruby-lang.org/issues/show/2048

The 1.8 behavior is an accidental feature, so that it should not be
used nor documented. I should fix 1.8 rather.

                        matz.

=end

#7

Updated by matz (Yukihiro Matsumoto) over 10 years ago

=begin
Hi,

In message "Re: [ruby-core:26056] Re: [Bug #2048] Thread#raise: Handling of Current Exception"
on Mon, 12 Oct 2009 13:54:21 +0900, Marc-Andre Lafortune ruby-core-mailing-list@marc-andre.ca writes:

|> The 1.8 behavior is an accidental feature, so that it should not be
|> used nor documented.  I should fix 1.8 rather.
|
|Oh.
|So should Thread#raise require at least one argument? Or else
|Thread#raise takes the exception being handled by the current thread
|and raises it in the receiving thread?

I'd rather leave it implementation dependent, but my intention is:
when Thread#raise is called without any argument, it would raise
RuntimeError without any message (as 1.9 does).

                        matz.

=end

Also available in: Atom PDF