Project

General

Profile

Actions

Bug #12068

closed

raise overwrites exception cause even if exception is not new

Added by headius (Charles Nutter) about 8 years ago. Updated almost 8 years ago.

Status:
Closed
Assignee:
-
Target version:
-
[ruby-core:73792]

Description

It appears that raise will overwrite the original cause of an exception even when re-raising the same one. I believe this is a bug, since loses the original cause and associates the re-raised exception with a completely unrelated cause.

Example:

begin
  begin
    raise 'a'
  rescue => a
    begin
      raise 'b'
    rescue => b
      p [b, b.cause]
      begin
        raise 'c'
      rescue
        raise b
      end
    end
  end
rescue
  p [$!, $!.cause]
end

CRuby outputs:

[] ~/projects/jruby $ ruby23 cause.rb
[#<RuntimeError: b>, #<RuntimeError: a>]
[#<RuntimeError: b>, #<RuntimeError: c>]

Here, the original cause of the "b" exception (the "a" exception) is lost, replaced during the re-raise with the "c" exception.

I believe JRuby 9.0.5.0's behavior is correct here:

[] ~/projects/jruby $ rvm jruby-9.0.5.0 do ruby cause.rb
[#<RuntimeError: b>, #<RuntimeError: a>]
[#<RuntimeError: b>, #<RuntimeError: a>]

Updated by nobu (Nobuyoshi Nakada) about 8 years ago

In JRuby, cause is set just in initialize?

$ jruby -v -e 'raise "a" rescue p RuntimeError.new("b").cause'
jruby 9.1.0.0-SNAPSHOT (2.2.3) 2016-02-14 c08ca7a Java HotSpot(TM) 64-Bit Server VM 25.25-b02 on 1.8.0_25-b17 +jit [darwin-x86_64]
#<RuntimeError: a>
$ ruby -v -e 'raise "a" rescue p RuntimeError.new("b").cause'
ruby 2.4.0dev (2016-02-13 trunk 53817) [universal.x86_64-darwin15]
nil

Updated by headius (Charles Nutter) about 8 years ago

Yes...the exception inherits current $! only in initialize, and carries it until overwritten.

Actions #3

Updated by nobu (Nobuyoshi Nakada) about 8 years ago

  • Status changed from Open to Closed

Applied in changeset r53819.


not overwrite cause

  • eval.c (setup_exception): set the cause only if it is explicitly
    given or not set yet. [Bug #12068]

Updated by headius (Charles Nutter) about 8 years ago

May I backport this change to 2.3? Matz? I believe the original behavior was unintentional and should be fixed.

Updated by nagachika (Tomoyuki Chikanaga) about 8 years ago

  • Backport changed from 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN to 2.0.0: DONTNEED, 2.1: REQUIRED, 2.2: REQUIRED, 2.3: REQUIRED

Please don't backport to the stable branches by yourself. The branch maintainers (usa and me) will do.

I fill Backport field.
I don't think the existing application depend on this behavior. Any opinions?

Updated by nagachika (Tomoyuki Chikanaga) almost 8 years ago

  • Backport changed from 2.0.0: DONTNEED, 2.1: REQUIRED, 2.2: REQUIRED, 2.3: REQUIRED to 2.0.0: DONTNEED, 2.1: REQUIRED, 2.2: REQUIRED, 2.3: DONE

ruby_2_3 r54617 merged revision(s) 53819,53822.

Updated by usa (Usaku NAKAMURA) almost 8 years ago

  • Backport changed from 2.0.0: DONTNEED, 2.1: REQUIRED, 2.2: REQUIRED, 2.3: DONE to 2.0.0: DONTNEED, 2.1: REQUIRED, 2.2: DONE, 2.3: DONE

ruby_2_2 r54675 merged revision(s) 53819,53822.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0