Issue #17930 has been updated by duerst (Martin D=FCrst).


mame (Yusuke Endoh) wrote in #note-22:
> Thank you for suggestions about the name. For the record, @pocke and @nar=
use like "pretty_error". I'll bring this to the next dev-meeting and ask @m=
atz to pick up.

I'm not convinced about "pretty_error". It's mostly an adjective, not a ver=
b. In that sense, "prettify_error" would be clearer. Also, most errors aren=
't pretty at all, and highlighting doesn't make them any prettier, or does =
it?

----------------------------------------
Feature #17930: Add column information into error backtrace
https://bugs.ruby-lang.org/issues/17930#change-92660

* Author: mame (Yusuke Endoh)
* Status: Assigned
* Priority: Normal
* Assignee: mame (Yusuke Endoh)
----------------------------------------
Consider the following code and error.

```
data["data"].first["field"] #=3D> undefined method `[]` for nil:NilClass
```

There are two possibilities; the variable `data` is nil, or the return valu=
e of `first` is nil. Unfortunately, the error message is less informative t=
o say which.

This proposal allows to help identifying which method call failed.

```
$ ruby -r ./sample/no_method_error_ext.rb err1.rb
err1.rb:2:in `<main>': undefined method `[]' for nil:NilClass (NoMethodErro=
r)

data["data"].first["field"]
                  ^^^^^^^^^
```

## Proposal

I'd like to propose a feature to get column information from each `Thread::=
BacktraceLocation`. Maybe it is good to provide the following four methods:

* `Thread::BacktraceLocation#first_lineno`
* `Thread::BacktraceLocation#first_column`
* `Thread::BacktraceLocation#last_lineno`
* `Thread::BacktraceLocation#last_column`

These names came from `RubyVM::AbstraceSyntaxTree::Node`'s methods.

## Implementation

Here is a proof-of-concept implementation: https://github.com/ruby/ruby/pul=
l/4540

See https://github.com/ruby/ruby/pull/4540/commits/6ff516f4985826e9f9c56066=
38001c3c420f7cad for an example usage.
(Note that, currently, you need to build ruby with `./configure cflags=3D-D=
EXPERIMENTAL_ISEQ_NODE_ID` to enable the feature.)

To put it simply, this PR provides only a raw API, `Thread::BacktraceLocati=
on#node_id`. To get actual column information, you need to manually identif=
y `RubyVM::AbstractSyntaxTree::Node` that corresponds to `Thread::Backtrace=
Location#node_id`.
But it would be arguable to expose "node_id", so I will wrap it as the abov=
e four methods if this is accepted.

Credit: the original implementation was done by @yui-knk.

## Drawback

To use this feature, we need to enable `-DEXPERIMENTAL_ISEQ_NODE_ID` to add=
 "node_id" information (a subtree ID of the original abstract syntax tree) =
into each byte code instruction. If we provide this feature, the option sho=
uld be enabled by default. However, the option increases memory consumption.

I performed a simple experiment: I created a scaffold app by `rails new`, a=
nd measured the memory usage after `rails s`. The result was 97 MB without =
`-DEXPERIMENTAL_ISEQ_NODE_ID`, and 100 MB with the option enabled.

In my opinion, it is not so large, but requiring more gems will increase th=
e difference. I will appriciate it if anyone could provide the actual memor=
y increase in a more practical Rails app.

Do you think this feature deserves the memory increase?

---Files--------------------------------
image.png (73.3 KB)


-- =

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

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>