Hugh Sasse wrote:
Charles D Hixson wrote:
In this case the bug was in the message not stating which variable had a
nil value. You may not think of it as serious, but he reports spending
several hours on it, and I'd call that a bug.
This is one of the things I find irritating as well. Normally Ruby
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. Remember
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 name
was called on in that code snippet.
...but in many conventionally constructed arithmetic expressions there
will be more than one plus sign. Some languages use an arrow
y = (a * x**3) + (b * x * x) + (c * x) + d
^
>
-----------------------+
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.
So it looks like Ruby does this occasionally itself.
[...]
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
Which doesn't apply in dynamic languages like Ruby where method creation
on the fly is the norm (attr_accessor, method_missing, and more).
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 diagnostics.
not the task of the interpreter itself.
Coding defensively and using sanity checks on the return value of #index
and other methods that may return nil would also have helped.
This doesn't mean that is is undesirable that Ruby do more. This is
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.
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
···
On Wed, 22 Nov 2006, David Vallner wrote:
