From: "İsmail Arılık" Date: 2015-03-20T09:27:31+02:00 Subject: [ruby-core:68568] Re: [Ruby trunk - Feature #10982] Clarify location of NoMethod error --001a11c30d14d9ca4b0511b33f41 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ``` foo.call && bar.call NoMethodError: undefined method `call' for nil:NilClass ``` I think this error already states that the method named `call` is undefined *for* the `nil` object of the `NilClass` class. So it is not necessary to change 'for' to 'on receiver'. 2015-03-20 0:47 GMT+02:00 : > Issue #10982 has been updated by Parker M. > > > This new syntax is a pretty sizable divergence from traditional Ruby erro= r > reporting. At the moment, errors generally (always?) have an accompanying > stack trace: > > ```text > ~$ ruby errors.rb > errors.rb:2:in `
': undefined method `call' for nil:NilClass > (NoMethodError) > ``` > > It indicates the line, but excludes the column. It's uniform for all > errors, so users seeing these stack traces know in what file, what line, > and what method (the binding?) the error occurred. If the proposed format > were implemented, would it only be for NoMethodError's, or would it apply > to ArgumentError's or TypeError's, and so on? > > Would the column number suffice? So your example would yield: > > ```text > irb:1:16:in `
': undefined method `call' for nil:NilClass > (NoMethodError) > ``` > > You'd know that line 1 at column 16 caused the error. > > ---------------------------------------- > Feature #10982: Clarify location of NoMethod error > https://bugs.ruby-lang.org/issues/10982#change-51880 > > * Author: Richard Schneeman > * Status: Open > * Priority: Normal > * Assignee: > ---------------------------------------- > In Ruby, the error `NoMethodError` on happens frequently, especially when > it occurs on `nil`. This error can be confusing to beginners since, many = of > them think there is a problem with the method instead of the receiver. Th= is > error can be confusing to advanced developers when there are multiple > method calls in the on the same line. In this example it is unclear if > `foo` or `bar` returned `nil`: > > ``` > foo.call && bar.call > NoMethodError: undefined method `call' for nil:NilClass > ``` > > I would like to make this a better error message and to indicate where th= e > exception occurs. > > ``` > @foo.call && @bar.call > ^---- > NoMethodError: The method `call` is undefined on receiver nil:NilClass > ``` > > Now it is more clear that the `@bar` is currently `nil` and that is the > source of the error. I believe exposing this information will help > developers of all abilities. > > > > > -- > https://bugs.ruby-lang.org/ > --=20 =C4=B0yi g=C3=BCnler. =C4=B0smail Ar=C4=B1l=C4=B1k --001a11c30d14d9ca4b0511b33f41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
```
foo.call && bar.call
NoMethodErro= r: undefined method `call' for nil:NilClass
```

I think this error already states that the metho= d named `call` is undefined *for* the `nil` object of the `NilClass` class.= So it is not necessary to change 'for' to 'on receiver'.

2015-03-20 0:= 47 GMT+02:00 <parkrmoore@gmail.com>:
Issue #10982 has been updated by Parker M.


This new syntax is a pretty sizable divergence from traditional Ruby error = reporting. At the moment, errors generally (always?) have an accompanying s= tack trace:

```text
~$ ruby errors.rb
errors.rb:2:in `<main>': undefined method `call' for nil:NilC= lass (NoMethodError)
```

It indicates the line, but excludes the column. It's uniform for all er= rors, so users seeing these stack traces know in what file, what line, and = what method (the binding?) the error occurred. If the proposed format were = implemented, would it only be for NoMethodError's, or would it apply to= ArgumentError's or TypeError's, and so on?

Would the column number suffice? So your example would yield:

```text
irb:1:16:in `<main>': undefined method `call' for nil:NilClas= s (NoMethodError)
```

You'd know that line 1 at column 16 caused the error.

----------------------------------------
Feature #10982: Clarify location of NoMethod error
https://bugs.ruby-lang.org/issues/10982#change-51880

* Author: Richard Schneeman
* Status: Open
* Priority: Normal
* Assignee:
----------------------------------------
In Ruby, the error `NoMethodError` on happens frequently, especially when i= t occurs on `nil`. This error can be confusing to beginners since, many of = them think there is a problem with the method instead of the receiver. This= error can be confusing to advanced developers when there are multiple meth= od calls in the on the same line. In this example it is unclear if `foo` or= `bar` returned `nil`:

```
foo.call && bar.call
NoMethodError: undefined method `call' for nil:NilClass
```

I would like to make this a better error message and to indicate where the = exception occurs.

```
@foo.call && @bar.call
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^----
NoMethodError: The method `call` is undefined on receiver nil:NilClass
```

Now it is more clear that the `@bar` is currently `nil` and that is the sou= rce of the error. I believe exposing this information will help developers = of all abilities.




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



--
=
=C4=B0yi g=C3=BCnler.<= /div>=C4=B0smail Ar=C4=B1l=C4=B1k
--001a11c30d14d9ca4b0511b33f41--