Leslie Viljoen
11/21/2006 10:28:00 PM
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