Re: [RANT] Error messages - was: [OT] Bug in ruby?

Hugh Sasse wrote:
> On Wed, 22 Nov 2006, David Vallner wrote:
>=20
>> Charles D Hixson wrote:
>>> In this case the bug was in the message not stating which variable ha=
d a
>>> nil value.  You may not think of it as serious, but he reports spendi=
ng
>>> several hours on it, and I'd call that a bug.
>=20
> This is one of the things I find irritating as well.  Normally Ruby=20
> is rightly praised for not getting in the way of productivity, but
> this really does force one to program to meet constraints which are
> not actually part of the language as such.
>> I'm not aware of a programming language that DOES report this. Remembe=
r
>=20
> Some other languages report things differently....
>         [...]
>> NullRefError in C#, or segfault in C would be. Since the undefined
>> method was #+, the culprit was the expression that a method of that na=
me
>> was called on in that code snippet.
>=20
> ...but in many conventionally constructed arithmetic expressions there
> will be more than one plus sign.   Some languages use an arrow
>        =20
>         y =3D (a * x**3) + (b * x * x) + (c * x) + d
>                        ^
>                        |
> -----------------------+
>=20
> or similar.  Evidence?  The %p construct in vim errorformats
> in compiler files for handling error messages, which uses
> the arrow to pick up the column:

You might want to look up the definition of evidence, this is stretching
the word way, WAY too far.

I haven't been able to get either .NET/C# or Java to show me where on a
line a NRE/NRE occured.

The arrows you mention are probably for compile-time errors. Read: while
the source code is being read, is present in it's textual
representation, and the errors detected are ones that can be determined
from the structure of the source code. A NPE is a *runtime* error, long
after the textual form of the code is under green pastures.

>=20
> So it looks like Ruby does this occasionally itself.
>         [...]
>=20

Probably for parse-time errors.

It is completely irrelevant if some languages detect some classes of
errors with precise source code locations, or that Ruby does this sort
of diagnostics at parse-time for other classes of errors than the one at
hand, when you can't bring a specific, valid counterexample to my
statement, which is that I can't recall a language that does that for
runtime errors, specifically of the dangling pointer class of errors.

Provide me with an example where a runtime problem in a complex
expression like the one you mentioned gives you exact source code
position, preferrably in a programming language I've actually heard of
before (there's enough of those), and I'll concede this point.

>> Further diagnostics (why it could have possibly happened) is the role =
of
>> a static code analysis tool; since it's sooner or later guesswork it's=

>=20
> Which doesn't apply in dynamic languages like Ruby where method creatio=
n
> on the fly is the norm (attr_accessor, method_missing, and more).
>=20

That's a price you pay for using a dynamic language with relatively
little mainstream penetration, those tools are harder to develop, have
to rely on less conclusive heuristics, there's a smaller market for them
and little chance of someone implementing them without a market because
they'd end up solving problems a lot of people consider a non-issue. If
you want tool support, Java beckons, otherwise wait until Ruby
equivalents emerge. It's also unrelated to the issue at hand.

Specifically, it doesn't imply (except in wishful thinking) that it
should be the job of the interpreter to provide possibly (probably)
unrelated "this -might- have gone wrong" type of information. The Ruby
interpreter's behaviour as it is is in my opinion correct and complete -
it provides the programmer with all the information it has at the time
from the information it needs to run the program. I am strongly opposed
to losing interpreter runtime efficiency (from keeping full program
source code intact in memory, for example) to provide heuristic diagnosti=
cs.

>> not the task of the interpreter itself.
>>
>> Coding defensively and using sanity checks on the return value of #ind=
ex
>> and other methods that may return nil would also have helped.
>=20
> This doesn't mean that is is undesirable that Ruby do more.  This is=20
> shifting the burden from the developers of ruby to the many users
> of it.  Not to suggest that the developers have all the time in the
> world, but to say that more people are affected by not having this than=

> are affected by having to implement it.
>=20

For me, it is undesirable. If it's a problem that can be solved within
the standard library by providing a set of DbC -ish metaprogramming
features, be it so. Same if it's a missing feature that can be
implemented without ambiguous output.

And for features that are clearly in the domain of code analysis tools,
I'm clearly against. Yes, such tools are absent in the Ruby domain. This
however doesn't imply the core interpreter should become one. I don't
want it to become a full-blown development tool, or any other form of
bloated monstrosity, the core responsibility of the interpreter is to
run Ruby code, and say when it can't stating the immediate reason why.

> Now, I would be the first to say that writing parsers is not easy.
> I have tried on a number of occasions, and frankly, I am rubbish at
> it.  Given the constraints imposed by YACC on the future of the
> language (see other threads in the past) I suspect that moving to
> some other parser may be helpful.  But the point of this post is
> that there is evidence from other languages that it is possible for
> Ruby to be more helpful, there is a desire among its users that it
> be more helpful.

I'll repeat that I haven't seen evidence that this class of errors is
diagnosed with the level of detail you'd like in a language with a
computation model similar to Ruby from you.


David Vallner