From: Leslie Viljoen <leslieviljoen@...>
Date: 2006-11-22T07:28:18+09:00
Subject: Re: [OT] Bug in ruby?

On 11/21/06, Charles D Hixson <charleshixsn@earthlink.net> wrote:
> 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!

I have also previously requested that this get fixed in a future Ruby.
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.

In some of my latest scripts I have this:

def preventNil(*args)
  args.each_with_index do |arg, i|
    raise ArgumentError.new("argument #{i} cannot be nil") if arg.nil?
  end
end

class StatSaver
  def initialize(vehicle, column, dataSet, log)

    preventNil(vehicle, column, dataSet, log)

    @vehicleID = vehicle.VehicleID
    @column = column
    @dataSet = dataSet
    @log = log
  end

...

...as a kind of firebreak contract to prevent nil's from failures in
completely unrelated places causing other code to fall over. You don't
always realise that a certain method might return nil.

I'd be interested to hear if there are nicer solutions to this problem.

Les