Misc #15568: TracePoint(:raise)#parameters raises RuntimeError

• Status: Open
• Assignee: -

[baweaver (Brandon Weaver)]

Currently trying to get the trace.parameters of a method in a raise event will lead to a RuntimeError. I would contend that it should not, and that it would be perfectly valid to ask for the parameters in the case of an exception.

The reason I do this is to see the arguments at the time of exception:

def extract_args(trace)
  trace.parameters.map(&:last).to_h do |name|
    [name, trace.binding.eval(name.to_s)]
  end
end

I've noticed that I can technically "cheat" and get these same values like this:

def extract_args(trace)
  trace.binding.eval('local_variables').to_h do |name|
    [name, trace.binding.eval(name.to_s)]
  end
end

Having the ability to get the parameters in a raise context would be very useful for debugging.

I'm tempted to also suggest TracePoint#local_variables as it would provide additional context in a more exposed way than TracePoint#binding.eval('local_variables')

[shevegen (Robert A. Heiler)]

Having the ability to get the parameters in a raise context would be very useful for debugging.

I agree. I can't say whether this means that trace.parameters exist but I agree that it may be
useful in debugging/introspection.

I'm tempted to also suggest TracePoint#local_variables as it would provide additional context in a
more exposed way than TracePoint#binding.eval('local_variables')

I can't say whether TracePoint#local_variables makes sense; but since the .eval() variant works,
I can see that it may just be a prettier and shorter name. I think it would be helpful to ask the
ruby core team about the API part here specifically, especially koichi and matz. I am not a big
user of TracePoint myself so I can not really speak about how useful it would be, but being able
to shorten the API and omitting eval, would seem ok to me. But perhaps others prefer eval(),
I don't know; eval() has a tiny bit of a hackish feeling to me personally though (I only mean
eval(), not the instance_eval() variants and the like). It seems an API consideration to me though
and a language designer's consideration (e. g. how matz would encourage ruby users to make
use of TracePoint; it's also a design decision what to enable or not to enable).