From: "KyleFromKitware (Kyle Edwards)" <noreply@...>
Date: 2022-05-20T19:25:11+00:00
Subject: [ruby-core:108643] [Ruby master Bug#16829] Exceptions raised from within an enumerated method lose part of their stacktrace

Issue #16829 has been updated by KyleFromKitware (Kyle Edwards).


> is it feasible to improve stacktraces raised within fibers?

As a more general solution, I'm wondering if exceptions could have not just a single stack trace, but an append-only list of stack traces that gets appended every time the exception is thrown or re-thrown. (It could retain `backtrace` and `set_backtrace` for compatibility.)

----------------------------------------
Bug #16829: Exceptions raised from within an enumerated method lose part of their stacktrace
https://bugs.ruby-lang.org/issues/16829#change-97689

* Author: doliveirakn (Kyle d'Oliveira)
* Status: Open
* Priority: Normal
* ruby -v: 2.7.1
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN
----------------------------------------
Consider the following code:

``` ruby
class Test
  include Enumerable

  def each(&block)
    raise "Boom"
  end
end

def execution_method_a
  Test.new.to_enum(:each).next
end

def execution_method_b
  Test.new.each do
    # Never gets run
  end
end

begin
  execution_method_a
rescue RuntimeError => e
  puts "Using to_enum and next"
  puts e.message
  puts e.backtrace
end


begin
  execution_method_b
rescue RuntimeError => e
  puts "Calling a block directly"
  puts e.message
  puts e.backtrace
end
```

When this file (located at lib/script.rb) is run the result is:
```
Using to_enum and next
Boom
lib/script.rb:5:in `each'
lib/script.rb:1:in `each'
Calling a block directly
Boom
lib/script.rb:5:in `each'
lib/script.rb:14:in `execution_method_b'
lib/script.rb:29:in `<main>'
```

This is a little unusual. Effectively, if we create an enumerator and use `next` to iterate through the results, the backtrace is modified to the point where the calling method(s) are entirely lose. Notice when the `each` method is used directly and an exception is thrown, we see `execution_method_b` present in the stacktrace, but if we use `next` we do not see `execution_method_a` present at all. 

This means that if there is some code that uses the enumerator/next approach deep within a callstack, the exception that comes out does not have any crucial information of where the call originated from. 



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>