Feature #17743: Show argument types in backtrace

• Status: Open
• Assignee: -
• Target version: -

[p8 (Petrik de Heus)]

Given the following Ruby program:

def say_hi(person)
  puts message(person)
end

def message(person)
  "hi: #{person.name}"
end

say_hi(nil)

It would be helpful if the backtrace contained the types of the argumets:

hi.rb:6:in `message': undefined method `name' for nil:NilClass (NoMethodError)
	from hi.rb:2:in `say_hi' called with NilClass
	from hi.rb:9:in `<main>' called with NilClass

Inspired by the following Twitter thread: https://twitter.com/lzsthw/status/1374350046909628423

[p8 (Petrik de Heus)]

• Description updated (diff)

[Eregon (Benoit Daloze)]

How would your format when the method takes multiple arguments?
Should we show the value or just the class?

I think in general this can be useful, but at the same time it's not nearly as useful as a debugger,
and it can be a significant performance overhead for JITs/VMs which would then need to collect all frames and arguments in every exception's backtrace, as well as a copy of the arguments array (instead of just [call site bci/node, called method name/target]).

[p8 (Petrik de Heus)]

Eregon (Benoit Daloze) wrote in #note-2:

How would your format when the method takes multiple arguments?

from hi.rb:2:in `say_hi' called with NilClass, Numeric, String

Should we show the value or just the class?

Values could possibly generate a lot of output and it might contain private data that you don't want to output.
Maybe for Boolean values showing true and false.

I think in general this can be useful, but at the same time it's not nearly as useful as a debugger,

I agree a debugger is more useful. This would mostly be useful for finding nils.

and it can be a significant performance overhead for JITs/VMs which would then need to collect all frames and arguments in every exception's backtrace, as well as a copy of the arguments array (instead of just [call site bci/node, called method name/target]).

I can imagine it being a performance overhead.

[ufuk (Ufuk Kayserilioglu)]

p8 (Petrik de Heus) wrote in #note-3:

from hi.rb:2:in `say_hi' called with NilClass, Numeric, String

What about keyword arguments that could have been supplied in any order? What about the block argument, if it was nil or not?

Maybe for Boolean values showing true and false.

There is no Boolean type in Ruby, so the output would naturally be TrueClass or FalseClass anyway. No need to special case this.

I can imagine it being a performance overhead.

This is a huge drawback for a nice-to-have feature, though.

[p8 (Petrik de Heus)]

ufuk (Ufuk Kayserilioglu) wrote in #note-4:

p8 (Petrik de Heus) wrote in #note-3:

from hi.rb:2:in `say_hi' called with NilClass, Numeric, String

What about keyword arguments that could have been supplied in any order? What about the block argument, if it was nil or not?

Hmm, hadn't thought about those and I can see this being problematic...

This is a huge drawback for a nice-to-have feature, though.

Hmm, yes I think I agree. This would probably be better handled by Static Typing and not allowing nils.