From: Justin Collins <collinsj@...>
Date: 2006-11-22T19:47:39+09:00
Subject: Re: [OT] Bug in ruby?

Leslie Viljoen wrote:
> On 11/22/06, David Vallner <david@vallner.net> wrote:
>> Leslie Viljoen wrote:
>> > It's very annoying to try and guess which could be the offending
>> > variable in a complex expression, and it wastes a lot of time. It
>> > would surely be very easy for Ruby to say which variable was nil.
>>
>> Meet my good friends, local variable, and return value checking. You'll
>> get along great once you get to know each other.
>>
>> Also, see previous post. At any given point in time, there's several
>> variables that point to nil in the interpreter, and the culprit is also
>> usually an expression. Finding the possible expressions that returned a
>> nil would require tracing back to the literal in the stack frames, and
>> even then the last one wouldn't have to be the cause of the problem. I
>> stand by my point that this is not the job of a core language runtime,
>> but of manual or automated code review.
>
> It just seems like it would be easier than that, since Ruby is an
> interpreter. Doesn't the last sub-expression get stored in a string
> somewhere as the expression is parsed?
>
> Anyway, I am just now noticing that 5+nil and nil+5 return different
> error messages. As long as an operator is unique in an expression, it
> should be easy to figure out which is nil.
>

The thing is, Ruby is not returning "nil" error messages, it's returning 
error messages which are consistent across all NoMethodError and 
TypeError exceptions (in these cases). More generally, nil is not 
getting any kind of special treatment. I think this is kind of nice, 
personally.

-Justin