# Bug in ruby? **URL:** \ **Category:** ruby-talk\ **Created:** [21 November 2006 03:15 UTC](https://rubytalk.org/t/bug-in-ruby/33110 "2006-11-21T03:15:37Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![AliasX\_Neo](https://avatars.discourse-cdn.com/v4/letter/a/c89c15/32.png) [@AliasX\_Neo](https://rubytalk.org/u/AliasX_Neo)\ **Post date:** [21 November 2006 03:15 UTC](https://rubytalk.org/t/bug-in-ruby/33110/1 "2006-11-21T03:15:37Z")
Well, I've spent the last hour or so debugging one of the stupidest errors I have encountered with Ruby. Let's see my code first: [code]def parse(string, starting, ending)         istart = string.index(starting) + starting.length         iend = string.index(ending, istart)         return string.slice(istart, iend - istart)     end[/code] This function is called about 13 times in my entire script. It breaks on the last one with this error: undefined method `+' for nil:NilClass Now, I have debugged the living hell out of this application. It's breaking on the first line, stating that starting.length is a nil object and that it can't perform a + operator in a nil object. The string that's getting passed into starting is: buy\_item.phtml? I debugged the application and put a mark on the first line to examine it in the following code: [code]def parse(string, starting, ending)         length = starting.length         istart = string.index(starting) + length         iend = string.index(ending, istart)         return string.slice(istart, iend - istart)     end[/code] And the debugger said that length was an int with the value of 15. Guess what still happened? Got the exact same error with the + operator on a nil object. Except that completely contradicts the fact that it's not nil but it's an int with the value of 15. I have spent the last hour trying hundreds of different forms of this code and am getting the same exact error every time. I've come to the conclusion that this must be some kind of bug in Ruby, I can not pull on piece of logical evidence out of this. So my last resort is you guru's here, what am I doing wrong? Is there some kind of magical law I broke? This application needs to get done tonight, and I really can't afford anymore time on this tiny little bug. Thanks in advanced. ~ Alias > **···** > > -- > Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/). ---
**Author:** ![Brabuhr](https://avatars.discourse-cdn.com/v4/letter/b/919ad9/32.png) [@Brabuhr](https://rubytalk.org/u/Brabuhr)\ **Post date:** [21 November 2006 03:24 UTC](https://rubytalk.org/t/bug-in-ruby/33110/2 "2006-11-21T03:24:26Z")
Wouldn't it be string.index() that is Nil here:     string.index(starting).+(starting.length) starting.length is a parameter to the '+' method being called on the result of index(). > **···** > > On 11/20/06, AliasX Neo \ wrote: > > > Well, I've spent the last hour or so debugging one of the stupidest > > errors I have encountered with Ruby. > > > > Let's see my code first: > > > > [code]def parse(string, starting, ending) > >         istart = string.index(starting) + starting.length > >         iend = string.index(ending, istart) > >         return string.slice(istart, iend - istart) > >     end[/code] > > > > This function is called about 13 times in my entire script. It breaks on > > the last one with this error: > > > > undefined method `+' for nil:NilClass > > > > Now, I have debugged the living hell out of this application. It's > > breaking on the first line, stating that starting.length is a nil object > > and that it can't perform a + operator in a nil object. The string > > that's getting passed into starting is: ---
**Author:** ![Collins\_Justin](https://avatars.discourse-cdn.com/v4/letter/c/e19adc/32.png) [@Collins\_Justin](https://rubytalk.org/u/Collins_Justin)\ **Post date:** [21 November 2006 03:26 UTC](https://rubytalk.org/t/bug-in-ruby/33110/3 "2006-11-21T03:26:54Z")
AliasX Neo wrote: > Well, I've spent the last hour or so debugging one of the stupidest errors I have encountered with Ruby. \ > I debugged the application and put a mark on the first line to examine it in the following code: > > [code]def parse(string, starting, ending) >         length = starting.length >         istart = string.index(starting) + length >         iend = string.index(ending, istart) >         return string.slice(istart, iend - istart) >     end[/code] > > And the debugger said that length was an int with the value of 15. Guess what still happened? Got the exact same error with the + operator on a nil object. Except that completely contradicts the fact that it's not nil but it's an int with the value of 15. >    > + is being called on string.index(starting) not length. I'd check to make sure you aren't getting nil from that: def parse(string, starting, ending)   p string.index(starting)         istart = string.index(starting) + length         iend = string.index(ending, istart)         return string.slice(istart, iend - istart) end Hope that helps. -Justin ---
**Author:** ![David\_Vallner](https://avatars.discourse-cdn.com/v4/letter/d/eb9ed0/32.png) [@David\_Vallner](https://rubytalk.org/u/David_Vallner)\ **Post date:** [21 November 2006 18:42 UTC](https://rubytalk.org/t/bug-in-ruby/33110/4 "2006-11-21T18:42:14Z")
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 ---
**Author:** ![Martin\_DeMello](https://avatars.discourse-cdn.com/v4/letter/m/f17d59/32.png) [@Martin\_DeMello](https://rubytalk.org/u/Martin_DeMello)\ **Post date:** [22 November 2006 11:15 UTC](https://rubytalk.org/t/bug-in-ruby/33110/5 "2006-11-22T11:15:40Z")
>         istart = string.index(starting) + starting.length [...] > undefined method `+' for nil:NilClass Other people have said this, but just to put it explicitly: Ruby has a message-passing object model - every operation consists of a message sent to an object. Thus, there are no symmetrical operations - even binary operations like + translate internally to one object being sent to the other as part of a "+" message. Indeed, you could even write the above as istart = string.index.starting.+(starting.length) to make it explicit that there's a method call going on under the hood. One consequence of this is that when an exception or error is thrown, it is thrown from the context of the receiving object. Thus "undefined method `+' for nil:NilClass" means you have attempted to call nil.+(something), not something.+(nil). That should help greatly in debugging stuff. martin > **···** > > On 11/21/06, AliasX Neo \ wrote: ---
**Author:** ![Paul\_Lutus](https://avatars.discourse-cdn.com/v4/letter/p/2bfe46/32.png) [@Paul\_Lutus](https://rubytalk.org/u/Paul_Lutus)\ **Post date:** [24 November 2006 19:47 UTC](https://rubytalk.org/t/bug-in-ruby/33110/6 "2006-11-24T19:47:32Z")
AliasX Neo wrote: > Well, I've spent the last hour or so debugging one of the stupidest > errors I have encountered with Ruby. It is a stupid error, but to say it diplomatically, the responsibility assignment is flawed. / ... > I have spent the last hour trying hundreds of different forms of this > code Except the one shown below. > and am getting the same exact error every time. I've come to the > conclusion that this must be some kind of bug in Ruby, I can not pull on > piece of logical evidence out of this. That is because you are not thinking hard enough. > So my last resort is you guru's here, what am I doing wrong? You are not breaking the problem down sufficiently. As others have commented, there are two operands for "+" and you have only looked at one of them. Do this: length = starting.length si = string.index(starting) if(length != nil && si != nil)   istart = si + length end > Is there some kind of magical law I broke? Yes, as a matter of fact, there is. You assumed there was a flaw in the language before exhausting the more obvious possibility that the error is your own. > This application needs to get done > tonight, and I really can't afford anymore time on this tiny little bug. Famous last words. > **···** > > -- > Paul Lutus > [http://www.arachnoid.com](http://www.arachnoid.com) ---
**Author:** ![Just\_Another\_Victim1](https://avatars.discourse-cdn.com/v4/letter/j/e56c9b/32.png) [@Just\_Another\_Victim1](https://rubytalk.org/u/Just_Another_Victim1)\ **Post date:** [24 November 2006 19:48 UTC](https://rubytalk.org/t/bug-in-ruby/33110/7 "2006-11-24T19:48:53Z")
"AliasX Neo" \ wrote in message news:86904d117a12656ca6e35c32fd8bcbe0@ruby-forum.com... > Well, I've spent the last hour or so debugging one of the stupidest > errors I have encountered with Ruby. > > Let's see my code first: > > [code]def parse(string, starting, ending) >        istart = string.index(starting) + starting.length >        iend = string.index(ending, istart) >        return string.slice(istart, iend - istart) >    end[/code] > > This function is called about 13 times in my entire script. It breaks on > the last one with this error: > > undefined method `+' for nil:NilClass     Just out of wild curiosity, did you ever figure this thing out? We're very eager to learn of bugs in Ruby so they may be fixed although it really looks like this was your error. Surely, it's not outrageous to think that string.index(starting) can return nil. Was this the case for you?     Thank you... ---
**Author:** ![Forum](https://avatars.discourse-cdn.com/v4/letter/f/43a26b/32.png) [@Forum](https://rubytalk.org/u/Forum)\ **Post date:** [21 November 2006 11:24 UTC](https://rubytalk.org/t/bug-in-ruby/33110/8 "2006-11-21T11:24:45Z")
> AliasX Neo wrote: > \> Well, I've spent the last hour or so debugging one of the stupidest > \> errors I have encountered with Ruby. > \> > \ > \> I debugged the application and put a mark on the first line to examine > \> it in the following code: > \> > \> [code]def parse(string, starting, ending) > \> length = starting.length > \> istart = string.index(starting) + length > \> iend = string.index(ending, istart) > \> return string.slice(istart, iend - istart) > \> end[/code] > \> > \> And the debugger said that length was an int with the value of 15. Guess > \> what still happened? Got the exact same error with the + operator on a > \> nil object. Except that completely contradicts the fact that it's not > \> nil but it's an int with the value of 15. > \> > > + is being called on string.index(starting) not length. I'd check to > make sure you aren't getting nil from that: which is expected behavior [http://www.ruby-doc.org/core/classes/String.html#M000805](http://www.ruby-doc.org/core/classes/String.html#M000805) cheers Robert def parse(string, starting, ending) > **···** > > On 11/21/06, Justin Collins \ wrote: > > >         p string.index(starting) > >         istart = string.index(starting) + length > >         iend = string.index(ending, istart) > >         return string.slice(istart, iend - istart) > > end > > > > Hope that helps. > > > > -Justin > > -- > The reasonable man adapts himself to the world; the unreasonable one > persists in trying to adapt the world to himself. Therefore all progress > depends on the unreasonable man. > > - George Bernard Shaw ---
**Author:** ![Charles\_D\_Hixson](https://avatars.discourse-cdn.com/v4/letter/c/e495f1/32.png) [@Charles\_D\_Hixson](https://rubytalk.org/u/Charles_D_Hixson)\ **Post date:** [21 November 2006 21:20 UTC](https://rubytalk.org/t/bug-in-ruby/33110/9 "2006-11-21T21:20:32Z")
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! ---
**Author:** ![Jim\_Cochrane](https://avatars.discourse-cdn.com/v4/letter/j/e9a140/32.png) [@Jim\_Cochrane](https://rubytalk.org/u/Jim_Cochrane)\ **Post date:** [24 November 2006 19:48 UTC](https://rubytalk.org/t/bug-in-ruby/33110/10 "2006-11-24T19:48:05Z")
So, how'd it go? Was it finished in time and under budget? 🙂 > **···** > > On 2006-11-21, Paul Lutus \ wrote: > > > AliasX Neo wrote: > > > > ... > > > > > This application needs to get done > > > tonight, and I really can't afford anymore time on this tiny little bug. > > > > Famous last words. > > -- ---
**Author:** ![Jim\_Cochrane](https://avatars.discourse-cdn.com/v4/letter/j/e9a140/32.png) [@Jim\_Cochrane](https://rubytalk.org/u/Jim_Cochrane)\ **Post date:** [24 November 2006 19:52 UTC](https://rubytalk.org/t/bug-in-ruby/33110/11 "2006-11-24T19:52:26Z")
It's not only not outrageous - if one reads the spec., it's obvious: ----------------------------------------------------------- String#index      str.index(substring [, offset]) =\> fixnum or nil      str.index(fixnum [, offset]) =\> fixnum or nil      str.index(regexp [, offset]) =\> fixnum or nil > **···** > > On 2006-11-22, Just Another Victim of the Ambient Morality \ wrote: > > > "AliasX Neo" \ wrote in message > > news:86904d117a12656ca6e35c32fd8bcbe0@ruby-forum.com... > > > > > Well, I've spent the last hour or so debugging one of the stupidest > > > errors I have encountered with Ruby. > > > > > > Let's see my code first: > > > > > > [code]def parse(string, starting, ending) > > >        istart = string.index(starting) + starting.length > > >        iend = string.index(ending, istart) > > >        return string.slice(istart, iend - istart) > > >    end[/code] > > > > > > This function is called about 13 times in my entire script. It breaks on > > > the last one with this error: > > > > > > undefined method `+' for nil:NilClass > > > >     Just out of wild curiosity, did you ever figure this thing out? We're > > very eager to learn of bugs in Ruby so they may be fixed although it really > > looks like this was your error. Surely, it's not outrageous to think that > > string.index(starting) can return nil. Was this the case for you? > > ------------------------------------------------------------------------ >      Returns the index of the first occurrence of the given \_substring\_, >      character (\_fixnum\_), or pattern (\_regexp\_) in \_str\_. Returns +nil+ >      if not found. If the second parameter is present, it specifies the >      position in the string to begin the search. > >         "hello".index('e') #=\> 1 >         "hello".index('lo') #=\> 3 >         "hello".index('a') #=\> nil >         "hello".index(101) #=\> 1 >         "hello".index(/[aeiou]/, -3) #=\> 4 > > -- ---
**Author:** ![Leslie\_Viljoen1](https://avatars.discourse-cdn.com/v4/letter/l/f1d935/32.png) [@Leslie\_Viljoen1](https://rubytalk.org/u/Leslie_Viljoen1)\ **Post date:** [21 November 2006 22:28 UTC](https://rubytalk.org/t/bug-in-ruby/33110/12 "2006-11-21T22:28:18Z")
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 > **···** > > On 11/21/06, Charles D Hixson \ 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! ---
**Author:** ![David\_Vallner](https://avatars.discourse-cdn.com/v4/letter/d/eb9ed0/32.png) [@David\_Vallner](https://rubytalk.org/u/David_Vallner)\ **Post date:** [22 November 2006 01:09 UTC](https://rubytalk.org/t/bug-in-ruby/33110/13 "2006-11-22T01:09:12Z")
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. I'm not aware of a programming language that DOES report this. Remember that a nil value can come out of a fairly complex expression instead of a single variable, and that nil can have many variables bound to it at a given moment. The bug was in the OP's code, plain and simple, it's not the responsibility of the programming language to do in-depth diagnosis of dangling pointer problems. Also, in the OP, the error message was consistent to Ruby's semantics - a NoMethodError on nil usually significates what a NPE in Java, 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. Ruby reported what happened consistently with its computation model (failed method lookup, nil being a regular object), and where it happened (with no less detail than any other programming language I've worked with reports on null pointers). 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 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. > Remember, Ruby is being recommended to total neophytes as a good > language to start with. That means that good diagnostic error messages > are essential! As is learning the syntax rules and how to read the error messages. Also, whoever makes that recommendation is a fool, and I'm not responsible for him making that wrong recommendation. AFAIK, the Ruby language presumes the programmer is a grownup, and there's a LOT of running with scissors involved. The simplicity makes it easy to pickup, but in my opinion it gets very difficult to hobble along with only basic knowledge and get something working done as the emergent behaviours "noone tells you about" bite you if you don't either delve deeper into how stuff works to avoid those errors, or get a broader overview of what's available to end up writing less code (e.g. replacing futzing around with substrings with a RE.) David Vallner ---
**Author:** ![Bill\_Kelly](https://avatars.discourse-cdn.com/v4/letter/b/cc9497/32.png) [@Bill\_Kelly](https://rubytalk.org/u/Bill_Kelly)\ **Post date:** [22 November 2006 04:05 UTC](https://rubytalk.org/t/bug-in-ruby/33110/14 "2006-11-22T04:05:49Z")
> 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.) Have you thought through how this might work? It seems the obvious solution may not generate useful information. See for ex: [http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/209336](http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/209336) Regards, Bill > **···** > > From: "Charles D Hixson" \ ---
**Author:** ![Paul\_Lutus](https://avatars.discourse-cdn.com/v4/letter/p/2bfe46/32.png) [@Paul\_Lutus](https://rubytalk.org/u/Paul_Lutus)\ **Post date:** [24 November 2006 19:47 UTC](https://rubytalk.org/t/bug-in-ruby/33110/15 "2006-11-24T19:47:47Z")
Charles D Hixson wrote: / ... > 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. But the interpreter cannot do that without reading the programmer's mind. Maybe the programmer intended to complete the loop in some code, not yet written, that extends beyond the present end of the program. The evidence is that the interpreter's scanner ended up at the end of the file, still happy with the syntax up to that point. > (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.) It is not a bug in Ruby if the incomplete loop could in principle continue beyond EOF. > 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. It is not a bug, at least, not in Ruby. At the point at which the error condition arises, the '+' method doesn't know the names of the variables that produced its inputs, it only knows that one of them is nil. Remember that this is a runtime error. And the OP used a debugger but still didn't realize there was a possibility he hadn't considered. This is not something any finite-sized language can possibly deal with. Also remember: in an interpreted language, every increase in hand-holding runtime comprehensiveness decreases execution speed. > Remember, Ruby is being recommended to total neophytes as a good > language to start with. That means that good diagnostic error messages > are essential! It also means that, as in all computer programming for all time, neophytes have to pay attention to details. The single most difficult part of learning how to program is to fully grasp how simple-minded computers actually are. Successful programmers know exactly how a computer will react to their code. Learning this, reducing it to a matter of instinct, takes time. > **···** > > -- > Paul Lutus > [http://www.arachnoid.com](http://www.arachnoid.com) ---
**Author:** ![Paul\_Lutus](https://avatars.discourse-cdn.com/v4/letter/p/2bfe46/32.png) [@Paul\_Lutus](https://rubytalk.org/u/Paul_Lutus)\ **Post date:** [24 November 2006 19:48 UTC](https://rubytalk.org/t/bug-in-ruby/33110/16 "2006-11-24T19:48:11Z")
Jim Cochrane wrote: > > AliasX Neo wrote: > > > > ... > > > > > This application needs to get done > > > tonight, and I really can't afford anymore time on this tiny little bug. > > > > Famous last words. > > So, how'd it go? Was it finished in time and under budget? 🙂 I think the OP is a student, in any case someone who isn't that into programming as recreation. Professionals don't conceptualize program flaws as "this tiny little bug". There is no such thing. All the tiny little bugs that weren't so tiny ... the one that disabled a US Navy destroyer running NT (after someone entered a zero into a user-level application and precipitated a divide-by-zero error that brought down the entire network), which then drifted out of control as the sailor geeks tried to restart the network. The bug that caused the Airbus to fly into the trees during an air show low pass (passengers on board). The microcode bug that caused Intel processors to produce incorrect math results, and damaged their reputation for a while. The bug that cause Mars Polar Explorer to prematurely shut down its engine and fall the last 100 meters to the surface of Mars, never to be heard from again. "Tiny little bug." No such thing. > **···** > > > On 2006-11-21, Paul Lutus \ wrote: > > -- > Paul Lutus > [http://www.arachnoid.com](http://www.arachnoid.com) ---
**Author:** ![David\_Vallner](https://avatars.discourse-cdn.com/v4/letter/d/eb9ed0/32.png) [@David\_Vallner](https://rubytalk.org/u/David_Vallner)\ **Post date:** [22 November 2006 01:13 UTC](https://rubytalk.org/t/bug-in-ruby/33110/17 "2006-11-22T01:13:54Z")
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. David Vallner ---
**Author:** ![Charles\_D\_Hixson](https://avatars.discourse-cdn.com/v4/letter/c/e495f1/32.png) [@Charles\_D\_Hixson](https://rubytalk.org/u/Charles_D_Hixson)\ **Post date:** [22 November 2006 06:07 UTC](https://rubytalk.org/t/bug-in-ruby/33110/18 "2006-11-22T06:07:29Z")
Bill Kelly wrote: > From: "Charles D Hixson" \ > > > 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.) > > Have you thought through how this might work? It seems the obvious > solution may not generate useful information. See for ex: > [http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/209336](http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/209336) > > Regards, > > Bill I admitted it was a hard problem ... but, well,... if functions are defined, and begins/ends balance within them, it probably happened before or after that. Not guaranteed, as there might be internal functions, but probable. If it's an end that is missing (usual case) start parsing from inner constructs out. Etc. (FWIW, I normally comment my ends thusly:     end # initialize for just this reason. With Ruby syntax it is a REALLY hard problem. When this has occurred a few times I start really agreeing with the languages that do things like "end if" or "end def".) OTOH, it's also true that by compiling every time I enter a new definition I can generally handle this error with minimal problems .... but it would be a lot easier to include sufficient context markers to ensure localization of errors. ---
**Author:** ![Hugh\_Sasse](https://avatars.discourse-cdn.com/v4/letter/h/d6d6ee/32.png) [@Hugh\_Sasse](https://rubytalk.org/u/Hugh_Sasse)\ **Post date:** [22 November 2006 11:05 UTC](https://rubytalk.org/t/bug-in-ruby/33110/19 "2006-11-22T11:05:52Z")
> 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                        ^ > **···** > > On Wed, 22 Nov 2006, David Vallner wrote: >                        \> > -----------------------+ > > 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: > > /usr/local/share/vim/vim70/compiler/ant.vim: \%A\ %#[%.%#]\ %f:%l:\ %m,%-Z\ %#[%.%#]\ %p^,%C\ %#[%.%#]\ %#%m > /usr/local/share/vim/vim70/compiler/bdf.vim: \%-Z%p^, > /usr/local/share/vim/vim70/compiler/eruby.vim: \%-Z%p^, > /usr/local/share/vim/vim70/compiler/fortran\_cv.vim: \%-Z%p%^%.%#, > /usr/local/share/vim/vim70/compiler/fortran\_elf90.vim: \%C%p\|, > /usr/local/share/vim/vim70/compiler/fortran\_g77.vim: \%-C\ \ \ %p%\*[0123456789^]%.%#, > /usr/local/share/vim/vim70/compiler/hp\_acc.vim: \%Z\ \ \ \ %p^%.%#, > /usr/local/share/vim/vim70/compiler/icc.vim:CompilerSet errorformat=%-Z%p^,%f(%l):\ remark\ #%n:%m,%f(%l)\ :\ (col.\ %c)\ remark:\ %m,%E%f(%l):\ error:\ %m,%E%f(%l):\ error:\ #%n:\ %m,%W%f(%l):\ warning\ #%n:\ %m,%W%f(%l):\ warning:\ %m,%-C%.%# > /usr/local/share/vim/vim70/compiler/intel.vim: \%-Z\ \ %p^, > /usr/local/share/vim/vim70/compiler/irix5\_c.vim: \%-Z\ %p^, > /usr/local/share/vim/vim70/compiler/irix5\_cpp.vim: \%-Z\ \ %p%^, > /usr/local/share/vim/vim70/compiler/javac.vim:CompilerSet errorformat=%E%f:%l:\ %m,%-Z%p^,%-C%.%#,%-G%.%# > /usr/local/share/vim/vim70/compiler/mips\_c.vim: \%-Z\ \ %p^, > /usr/local/share/vim/vim70/compiler/mipspro\_c89.vim: \%-Z%p%^, > /usr/local/share/vim/vim70/compiler/mipspro\_cpp.vim: \%-Z\ \ %p^, > /usr/local/share/vim/vim70/compiler/ruby.vim: \%-Z%p^, > /usr/local/share/vim/vim70/compiler/xmllint.vim: \%-Z%p^, > > So it looks like Ruby does this occasionally itself. > > > > >         [...] > > > 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). > > > 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. > > 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. The next question, which I can't answer given my > weaknesses in this area, is: how can this be improved? Or, > conversely, can it be shown that improving it would be detrimental > to Ruby in some important way? > > We know Ruby is excellent. That's why we'd like it to be even better. >          >         Hugh ---
**Author:** ![Jim\_Cochrane](https://avatars.discourse-cdn.com/v4/letter/j/e9a140/32.png) [@Jim\_Cochrane](https://rubytalk.org/u/Jim_Cochrane)\ **Post date:** [24 November 2006 19:48 UTC](https://rubytalk.org/t/bug-in-ruby/33110/20 "2006-11-24T19:48:27Z")
> Jim Cochrane wrote: > > > > AliasX Neo wrote: > > > > > > ... > > > > > > > This application needs to get done > > > > tonight, and I really can't afford anymore time on this tiny little bug. > > > > > > Famous last words. > > > > So, how'd it go? Was it finished in time and under budget? 🙂 > > I think the OP is a student, in any case someone who isn't that into > programming as recreation. Yes, that's pretty apparent - I was being jocular, or perhaps, facetious. 🙂 > Professionals don't conceptualize program flaws as "this tiny little bug". You would hope not, but from what I've seen in the industry, I'd not be surprised to hear about such a statement. > There is no such thing. All the tiny little bugs that weren't so tiny ... > the one that disabled a US Navy destroyer running NT (after someone entered > a zero into a user-level application and precipitated a divide-by-zero > error that brought down the entire network), which then drifted out of > control as the sailor geeks tried to restart the network. The bug that > caused the Airbus to fly into the trees during an air show low pass > (passengers on board). > > The microcode bug that caused Intel processors to produce incorrect math > results, and damaged their reputation for a while. Yep - famous bugs. > The bug that cause Mars Polar Explorer to prematurely shut down its engine > and fall the last 100 meters to the surface of Mars, never to be heard from > again. Due to a missing or incorrect unit conversion, right?! > "Tiny little bug." No such thing. Or how about the Ariane 5 ( [http://www.around.com/ariane.html](http://www.around.com/ariane.html) ). I don't remember ever hearing a description of the defect (or defects) that caused the DIA baggage sysgtem to fail ( [http://www.cis.gsu.edu/~mmoore/CIS3300/handouts/SciAmSept1994.html](http://www.cis.gsu.edu/~mmoore/CIS3300/handouts/SciAmSept1994.html) ). Maybe a more severe word than "bug" needs to be invented. > **···** > > On 2006-11-22, Paul Lutus \ wrote: > > > > On 2006-11-21, Paul Lutus \ wrote: > > -- [Next page](https://rubytalk.org/t/bug-in-ruby/33110.md?page=2)