[ruby-core:91292] [Ruby trunk Misc#15568] TracePoint(:raise)#parameters raises RuntimeError

[ruby-core:91292] [Ruby trunk Misc#15568] TracePoint(:raise)#parameters raises RuntimeError

[keystonelemur]

Issue #15568 has been reported by baweaver (Brandon Weaver).

----------------------------------------
Misc #15568: TracePoint(:raise)#parameters raises RuntimeError
https://bugs.ruby-lang.org/issues/15568

* Author: baweaver (Brandon Weaver)
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
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')`



-- 
https://bugs.ruby-lang.org/

[ruby-core:91298] [Ruby trunk Misc#15568] TracePoint(:raise)#parameters raises RuntimeError

[shevegen]

Issue #15568 has been updated by 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).

----------------------------------------
Misc #15568: TracePoint(:raise)#parameters raises RuntimeError
https://bugs.ruby-lang.org/issues/15568#change-76543

* Author: baweaver (Brandon Weaver)
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
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')`



-- 
https://bugs.ruby-lang.org/