Project

General

Profile

Actions

Feature #17743

open

Show argument types in backtrace

Added by p8 (Petrik de Heus) over 3 years ago. Updated over 3 years ago.

Status:
Open
Assignee:
-
Target version:
-
[ruby-core:102988]

Description

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

Actions #1

Updated by p8 (Petrik de Heus) over 3 years ago

  • Description updated (diff)

Updated by Eregon (Benoit Daloze) over 3 years ago

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]).

Updated by p8 (Petrik de Heus) over 3 years ago

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.

Updated by ufuk (Ufuk Kayserilioglu) over 3 years ago

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.

Updated by p8 (Petrik de Heus) over 3 years ago

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.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0