From: "Eregon (Benoit Daloze) via ruby-core" <ruby-core@ml.ruby-lang.org>
To: ruby-core@ml.ruby-lang.org
Cc: "Eregon (Benoit Daloze)" <noreply@ruby-lang.org>
Subject: [ruby-core:121348] [Ruby master Misc#20968] `Array#fetch_values` unexpected method name in stack trace
Date: Thu, 13 Mar 2025 14:25:42 +0000 (UTC) [thread overview]
Message-ID: <redmine.journal-112320.20250313142542.9869@ruby-lang.org> (raw)
In-Reply-To: <redmine.issue-20968.20241219054042.9869@ruby-lang.org>
Issue #20968 has been updated by Eregon (Benoit Daloze).
matz (Yukihiro Matsumoto) wrote in #note-13:
> It should not be displayed. I don't care much if it exists. It should be decided according to the demand and implementation easiness.
FWIW, I am pretty sure TruffleRuby will never do that change.
It would hide crucial information for both users and implementation developers, as I detailed above.
We tried it in TruffleRuby, it was bad for both users and devs, we learned from it.
It's like hiding crucial debugging information from segfault reports, who would want that?
To be frank, I think it's shortsighted to do anything about this now.
The problem of hiding will naturally become more evident as more of the Ruby core library is defined in Ruby.
`Primitive.attr! :c_trace` can be used on `Array#fetch_values`, I don't really care about that specific one (except obviously we wouldn't hide it on TruffleRuby).
But in general I think it's clearly a mistake to hide those backtrace entries which are helpful to understand behavior.
It's like silently swallowing exceptions, it wastes tons of time in debugging for little value.
It's also not the Ruby VM's job to hide frames, it should show all of them to ease debugging.
Test frameworks might choose to filter stacktraces or display them differently, that's fine, and it's easy.
All the test frameworks that I know and filter also provide an option to opt out of that filtering, proving that it's sometimes necessary to have the full stacktrace.
There are no practical problems with it (just people learning about it/getting used to it because it was less common).
In fact `<internal` exists since at least Ruby 2.3, probably even before.
A common example, from Ruby 3.0 is `Kernel#tap` (AFAIK nobody ever complained or got confused about it):
```
$ ruby -e 'tap { raise "oops" }'
-e:1:in `block in <main>': oops (RuntimeError)
from <internal:kernel>:90:in `tap'
from -e:1:in `<main>'
```
The suggested change would result in:
```
$ ruby -e 'tap { raise "oops" }'
-e:1:in `block in <main>': oops (RuntimeError)
from -e:1:in `tap'
from -e:1:in `<main>'
```
which is no better and would make debugging far worse if there are multiple `<internal` frames.
---
I'll give another example where the proposed change hurts understandability:
Suppose Method#call is defined in Ruby code, then this change proposes to go from:
```
...
from bar.rb:1:in 'Bar#bar'
from foo.rb:1:in 'block in Foo#foo'
from <internal:kernel>:90:in 'Kernel#tap'
from <internal:method>:111:in 'Method#call'
from foo.rb:1:in 'Foo#foo'
...
```
to
```
...
from bar.rb:1:in 'Bar#bar'
from foo.rb:1:in 'block in Foo#foo'
from <internal:method>:111:in 'Method#call'
from foo.rb:1:in 'Foo#foo'
...
```
So now Method#call can call a block directly?
No, it's just the stacktrace betraying you by hiding crucial information.
(there are more examples which don't even need methods to move from C to Ruby in previous comment https://bugs.ruby-lang.org/issues/20968#note-6)
----------------------------------------
Misc #20968: `Array#fetch_values` unexpected method name in stack trace
https://bugs.ruby-lang.org/issues/20968#change-112320
* Author: koic (Koichi ITO)
* Status: Open
----------------------------------------
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.
```console
$ 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.
```console
$ 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.
--
https://bugs.ruby-lang.org/
______________________________________________
ruby-core mailing list -- ruby-core@ml.ruby-lang.org
To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/
next prev parent reply other threads:[~2025-03-13 14:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-19 5:40 [ruby-core:120315] [Ruby master Bug#20968] " koic (Koichi ITO) via ruby-core
2024-12-19 6:20 ` [ruby-core:120316] " jeremyevans0 (Jeremy Evans) via ruby-core
2024-12-19 7:53 ` [ruby-core:120320] " byroot (Jean Boussier) via ruby-core
2024-12-19 8:37 ` [ruby-core:120324] " koic (Koichi ITO) via ruby-core
2025-02-18 10:59 ` [ruby-core:121100] " Eregon (Benoit Daloze) via ruby-core
2025-02-18 18:40 ` [ruby-core:121107] " mame (Yusuke Endoh) via ruby-core
2025-02-18 23:19 ` [ruby-core:121116] " Eregon (Benoit Daloze) via ruby-core
2025-02-19 1:47 ` [ruby-core:121119] [Ruby master Misc#20968] " jeremyevans0 (Jeremy Evans) via ruby-core
2025-02-19 9:58 ` [ruby-core:121122] " Eregon (Benoit Daloze) via ruby-core
2025-03-02 22:18 ` [ruby-core:121216] " ioquatix (Samuel Williams) via ruby-core
2025-03-13 11:06 ` [ruby-core:121325] " mame (Yusuke Endoh) via ruby-core
2025-03-13 11:09 ` [ruby-core:121326] " byroot (Jean Boussier) via ruby-core
2025-03-13 12:07 ` [ruby-core:121337] " matz (Yukihiro Matsumoto) via ruby-core
2025-03-13 14:25 ` Eregon (Benoit Daloze) via ruby-core [this message]
2025-03-14 7:12 ` [ruby-core:121360] [Ruby " mame (Yusuke Endoh) via ruby-core
2025-03-14 9:51 ` [ruby-core:121362] " Eregon (Benoit Daloze) via ruby-core
2025-04-08 3:22 ` [ruby-core:121569] " hsbt (Hiroshi SHIBATA) via ruby-core
2025-04-08 17:34 ` [ruby-core:121593] " Dan0042 (Daniel DeLorme) via ruby-core
2025-04-15 8:01 ` [ruby-core:121665] " akr (Akira Tanaka) via ruby-core
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=redmine.journal-112320.20250313142542.9869@ruby-lang.org \
--to=ruby-core@ml.ruby-lang.org \
--cc=noreply@ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).