Bug #20968: `Array#fetch_values` unexpected method name in stack trace

• Status: Open
• Assignee: -
• Target version: -
• ruby -v: ruby 3.4.0dev (2024-12-19T04:44:56Z master 2783868de2) +PRISM [x86_64-darwin23]
• Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN

[koic (Koichi ITO)]

It seems that the current Ruby implementation is displaying unexpected method name in stack trace.

Expected

Similar to Hash#fetch_values, the method name Array#fetch_values is expected to be displayed in the stack trace.

$ ruby -e '{k: 42}.fetch_values(:unknown)'
-e:1:in 'Hash#fetch_values': key not found: :unknown (KeyError)
        from -e:1:in '<main>'

$ ruby -e '[1].fetch_values(42)'
-e:1:in 'Array#fetch_values': index 42 outside of array bounds: -1...1 (IndexError)
        from -e:1:in '<main>'

Actual

The stack trace displays the Array#fetch method, which user is not aware of, along with the <internal.array> stack trace.

$ ruby -e '[1].fetch_values(42)'
<internal:array>:211:in 'Array#fetch': index 42 outside of array bounds: -1...1 (IndexError)
        from <internal:array>:211:in 'block in Array#fetch_values'
        from <internal:array>:211:in 'Array#map!'
        from <internal:array>:211:in 'Array#fetch_values'
        from -e:1:in '<main>'

It likely requires an approach such as implementing it in C, as suggested in https://github.com/ruby/ruby/pull/11555.

[jeremyevans0 (Jeremy Evans)]

This doesn't seem like a bug to me. Array#fetch_values is in the backtrace, just not the top frame.

This isn't the only core method with the behavior:

1.ceildiv(0)
# <internal:numeric>:304:in 'Integer#div': divided by 0 (ZeroDivisionError)
#         from <internal:numeric>:304:in 'Integer#ceildiv'

As more core methods are implemented in Ruby, this situation will occur more frequently. Can you explain why you think this is a bug? This is the expected behavior for most methods in the standard library, as well as most methods in gems. Any method written in Ruby that calls other methods will have this behavior, so I think it is OK that core methods are allowed to have this behavior.

[byroot (Jean Boussier)]

I agree with @jeremyevans0 (Jeremy Evans) that it's not a bug.

But if it's decided than it is, then there's no need to rewrite it all in C, you can just set the c_trace attribute:

Primitive.attr! :c_trace

[koic (Koichi ITO)]

Thank you for your prompt response.
I hadn’t realized that the same issue occurs with 1.ceildiv(0) as well.

This is not a bug, but my concern arises from the asymmetry in how exceptions are displayed for Array#fetch_values. Even though Array#fetch_values was used incorrectly, the backtrace displays Array#fetch at the top, which was not explicitly called, and this caused some confusion.

This is just a personal opinion, but it seems more natural for exception related to Array#fetch_values to show Array#fetch_values itself instead of the internal implementation of Array#fetch. This is not specific to Array#fetch_values, as the same can be said for cases like 1.ceildiv(0).