David Vallner wrote:
> This is a subject line that's mildly infuriating. I wonder if I can
> recall more than three threads of that name that actually were a bug in
> Ruby after all in the past year, and the one that's in living memory was
> from Ara, and (unsurprisingly) a very subtle issue where it took me
> three reads to find out why it's wrong behaviour in the first place, not
> a "method not working at all" issue.
>
> If you're not a syntax lawyer, and / or haven't checked the
> documentation for what you're using a code snippet in the first place,
> I'd say odds are good it's a bug in your code due to some (maybe not
> really) gotcha you overlooked. And in that case it would be better to
> present a problem as such, and providing a more informative subject line
> to boot.
>
> Also:
>
> def parse(string, start, ending)
>  string.match(/#{Regexp.escape(start)}.*(?=#{Regexp.escape(ending)}/)[0]
> end
>
> David Vallner
>
>   
There have been many that I thought were "bugs in Ruby", though mainly 
in the error message produced rather than that the code should have done 
what the person objecting thought it should have done.

I'll grant that good error messages are a hard problem, but I frequently 
find them totally exasperating.  E.g., if a loop isn't properly closed, 
the error message should point to where it started rather than several 
lines after the end of the program.  (Well, perhaps this one's been 
fixed.  I don't remember encountering it recently.  But if it hasn't 
been, I consider it a bug in Ruby.)

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.

Remember, Ruby is being recommended to total neophytes as a good 
language to start with.  That means that good diagnostic error messages 
are essential!