Bug in ruby?

Discussion in 'Ruby' started by AliasX Neo, Nov 21, 2006.

  1. AliasX Neo

    AliasX Neo Guest

    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
    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
    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/.
    AliasX Neo, Nov 21, 2006
    #1
    1. Advertising

  2. AliasX Neo

    Guest

    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
    >
    > 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:


    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().
    , Nov 21, 2006
    #2
    1. Advertising

  3. AliasX Neo wrote:
    > Well, I've spent the last hour or so debugging one of the stupidest
    > errors I have encountered with Ruby.
    >
    >

    <snip>
    > 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
    >
    > 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
    Justin Collins, Nov 21, 2006
    #3
  4. Re: [OT] Bug in ruby?

    --------------enigA22C6AD12A9F315A34DABA54
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: quoted-printable

    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)}.*(?=3D#{Regexp.escape(ending)}/)[0=
    ]
    end

    David Vallner


    --------------enigA22C6AD12A9F315A34DABA54
    Content-Type: application/pgp-signature; name="signature.asc"
    Content-Description: OpenPGP digital signature
    Content-Disposition: attachment; filename="signature.asc"

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (MingW32)

    iD8DBQFFY0h9y6MhrS8astoRAqNMAJ9g6k2hcMDwQrkuq05MkuwIcC5THQCfVYDZ
    +cw08/DT2YWa2gnQMEZlRIo=
    =bibf
    -----END PGP SIGNATURE-----

    --------------enigA22C6AD12A9F315A34DABA54--
    David Vallner, Nov 21, 2006
    #4
  5. Re: [OT] Bug in ruby?

    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!
    Charles D Hixson, Nov 21, 2006
    #5
  6. Re: [OT] Bug in ruby?

    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!


    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
    Leslie Viljoen, Nov 21, 2006
    #6
  7. AliasX Neo

    Jim Cochrane Guest

    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.
    >


    So, how'd it go? Was it finished in time and under budget? :)

    --
    Jim Cochrane, Nov 22, 2006
    #7
  8. Re: [OT] Bug in ruby?

    --------------enig5F9F2435D66B717CB6ECCC13
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: quoted-printable

    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.
    >=20


    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


    --------------enig5F9F2435D66B717CB6ECCC13
    Content-Type: application/pgp-signature; name="signature.asc"
    Content-Description: OpenPGP digital signature
    Content-Disposition: attachment; filename="signature.asc"

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (MingW32)

    iD8DBQFFY6M0y6MhrS8astoRAiF3AJ9vvDIKyGkSrz9L/aTLvpeYv3jO9gCeIb7B
    +0wvx2EFK2EHrxRr0qMoeWU=
    =ynJm
    -----END PGP SIGNATURE-----

    --------------enig5F9F2435D66B717CB6ECCC13--
    David Vallner, Nov 22, 2006
    #8
  9. Re: [OT] Bug in ruby?

    --------------enig2AE4673C523F1A1434A02A91
    Content-Type: text/plain; charset=ISO-8859-1
    Content-Transfer-Encoding: quoted-printable

    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


    --------------enig2AE4673C523F1A1434A02A91
    Content-Type: application/pgp-signature; name="signature.asc"
    Content-Description: OpenPGP digital signature
    Content-Disposition: attachment; filename="signature.asc"

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (MingW32)

    iD8DBQFFY6ROy6MhrS8astoRAqlHAJ918cvfNYdoVcFjhRgfzUnPVpQWcwCfQ0Jy
    9eNwpxXQrqCTIALyDRXY2co=
    =hS+h
    -----END PGP SIGNATURE-----

    --------------enig2AE4673C523F1A1434A02A91--
    David Vallner, Nov 22, 2006
    #9
  10. AliasX Neo

    Jim Cochrane Guest

    On 2006-11-22, Paul Lutus <> wrote:
    > Jim Cochrane wrote:
    >
    >> 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.
    >>>

    >>
    >> 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
    ). 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
    ).

    Maybe a more severe word than "bug" needs to be invented.

    --
    Jim Cochrane, Nov 22, 2006
    #10
  11. AliasX Neo

    Bill Kelly Guest

    Re: [OT] Bug in ruby?

    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



    Regards,

    Bill
    Bill Kelly, Nov 22, 2006
    #11
  12. Re: [OT] Bug in ruby?

    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
    >
    >
    >
    > 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.
    Charles D Hixson, Nov 22, 2006
    #12
  13. Re: [OT] Bug in ruby?

    On 11/22/06, David Vallner <> 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.
    Leslie Viljoen, Nov 22, 2006
    #13
  14. "AliasX Neo" <> wrote in message
    news:...
    > 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
    >
    > 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...
    Just Another Victim of the Ambient Morality, Nov 22, 2006
    #14
  15. Re: [OT] Bug in ruby?

    On 21.11.2006 23:28, Leslie Viljoen wrote:
    > On 11/21/06, Charles D Hixson <> wrote:
    >> David Vallner 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.


    Frankly, in this case I would attribute that to the bug searcher and not
    the language. The message is pretty clear, it gives a line number and
    an easy explanation. With that, you can immediately spot where it goes
    wrong - even if you are unsure whether to look at the right or left side
    of the "+".

    >> 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.


    Actually I am not sure about this. The reason is this: the fact that
    the method does not exist in the receiver is not detected prior to
    runtime. And the object in question could potentially be referenced via
    any number of variables (including being part of an Array). As such the
    interpreter would have to remember several variable names per thread per
    object to actually be able to resolve this properly. Or it would have
    to go back to the source to determine this. And what do you do in this
    case where it is the result of a method call? As you see, it is not
    that easy and can incur some overhead you might not want to pay either.

    Having said that, nobody forces you to create complex expressions. You
    can help readability and maintainability a lot if you break those down -
    which in turn makes debugging easier.

    > 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


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


    The problem I see here is that the fact it's not nil does not tell you
    that it is actually a proper value. So at best you only catch some
    errors with this approach.

    Kind regards

    robert
    Robert Klemme, Nov 22, 2006
    #15
  16. Re: [OT] Bug in ruby?

    Leslie Viljoen wrote:
    > On 11/22/06, David Vallner <> 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
    Justin Collins, Nov 22, 2006
    #16
  17. AliasX Neo

    Hugh Sasse Guest

    Re: Error messages - was: [OT] Bug in ruby?

    On Wed, 22 Nov 2006, David Vallner wrote:

    > 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
    ^
    |
    -----------------------+

    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
    Hugh Sasse, Nov 22, 2006
    #17
  18. Re: [OT] Bug in ruby?

    --------------enigAE0DCD69AD8736E4596C0D0E
    Content-Type: text/plain; charset=ISO-8859-1
    Content-Transfer-Encoding: quoted-printable

    Leslie Viljoen wrote:
    > On 11/22/06, David Vallner <> wrote:
    >> 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 als=

    o
    >> 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.

    >=20
    > 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?
    >=20


    Probably not, to my best knowledge, a source file is always tokenized
    and parsed into an AST before interpreting. The interpreter would have
    to do extra work to reconstruct the last expression, which might not
    really be helpful always, or even in most cases. (Someone with more
    information on the interpreter's internals could say this with more
    authority.)

    David Vallner


    --------------enigAE0DCD69AD8736E4596C0D0E
    Content-Type: application/pgp-signature; name="signature.asc"
    Content-Description: OpenPGP digital signature
    Content-Disposition: attachment; filename="signature.asc"

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (MingW32)

    iD8DBQFFZC8ty6MhrS8astoRAj7uAJ44DC10DF24CgOgMwA6Uluu4OrVmgCfa3ry
    Dh309YxFA1UKzYSz12i59fg=
    =Amwm
    -----END PGP SIGNATURE-----

    --------------enigAE0DCD69AD8736E4596C0D0E--
    David Vallner, Nov 22, 2006
    #18
  19. On 11/21/06, AliasX Neo <> wrote:

    > 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
    Martin DeMello, Nov 22, 2006
    #19
  20. Re: [RANT] Error messages - was: [OT] Bug in ruby?

    --------------enigD62F977933D999B110F27AC5
    Content-Type: text/plain; charset=ISO-8859-1
    Content-Transfer-Encoding: quoted-printable

    Hugh Sasse wrote:
    > On Wed, 22 Nov 2006, David Vallner wrote:
    >=20
    >> Charles D Hixson wrote:
    >>> In this case the bug was in the message not stating which variable ha=

    d a
    >>> nil value. You may not think of it as serious, but he reports spendi=

    ng
    >>> several hours on it, and I'd call that a bug.

    >=20
    > This is one of the things I find irritating as well. Normally Ruby=20
    > 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. Remembe=

    r
    >=20
    > 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 na=

    me
    >> was called on in that code snippet.

    >=20
    > ...but in many conventionally constructed arithmetic expressions there
    > will be more than one plus sign. Some languages use an arrow
    > =20
    > y =3D (a * x**3) + (b * x * x) + (c * x) + d
    > ^
    > |
    > -----------------------+
    >=20
    > 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:


    You might want to look up the definition of evidence, this is stretching
    the word way, WAY too far.

    I haven't been able to get either .NET/C# or Java to show me where on a
    line a NRE/NRE occured.

    The arrows you mention are probably for compile-time errors. Read: while
    the source code is being read, is present in it's textual
    representation, and the errors detected are ones that can be determined
    from the structure of the source code. A NPE is a *runtime* error, long
    after the textual form of the code is under green pastures.

    >=20
    > So it looks like Ruby does this occasionally itself.
    > [...]
    >=20


    Probably for parse-time errors.

    It is completely irrelevant if some languages detect some classes of
    errors with precise source code locations, or that Ruby does this sort
    of diagnostics at parse-time for other classes of errors than the one at
    hand, when you can't bring a specific, valid counterexample to my
    statement, which is that I can't recall a language that does that for
    runtime errors, specifically of the dangling pointer class of errors.

    Provide me with an example where a runtime problem in a complex
    expression like the one you mentioned gives you exact source code
    position, preferrably in a programming language I've actually heard of
    before (there's enough of those), and I'll concede this point.

    >> 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=


    >=20
    > Which doesn't apply in dynamic languages like Ruby where method creatio=

    n
    > on the fly is the norm (attr_accessor, method_missing, and more).
    >=20


    That's a price you pay for using a dynamic language with relatively
    little mainstream penetration, those tools are harder to develop, have
    to rely on less conclusive heuristics, there's a smaller market for them
    and little chance of someone implementing them without a market because
    they'd end up solving problems a lot of people consider a non-issue. If
    you want tool support, Java beckons, otherwise wait until Ruby
    equivalents emerge. It's also unrelated to the issue at hand.

    Specifically, it doesn't imply (except in wishful thinking) that it
    should be the job of the interpreter to provide possibly (probably)
    unrelated "this -might- have gone wrong" type of information. The Ruby
    interpreter's behaviour as it is is in my opinion correct and complete -
    it provides the programmer with all the information it has at the time
    from the information it needs to run the program. I am strongly opposed
    to losing interpreter runtime efficiency (from keeping full program
    source code intact in memory, for example) to provide heuristic diagnosti=
    cs.

    >> not the task of the interpreter itself.
    >>
    >> Coding defensively and using sanity checks on the return value of #ind=

    ex
    >> and other methods that may return nil would also have helped.

    >=20
    > This doesn't mean that is is undesirable that Ruby do more. This is=20
    > 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.
    >=20


    For me, it is undesirable. If it's a problem that can be solved within
    the standard library by providing a set of DbC -ish metaprogramming
    features, be it so. Same if it's a missing feature that can be
    implemented without ambiguous output.

    And for features that are clearly in the domain of code analysis tools,
    I'm clearly against. Yes, such tools are absent in the Ruby domain. This
    however doesn't imply the core interpreter should become one. I don't
    want it to become a full-blown development tool, or any other form of
    bloated monstrosity, the core responsibility of the interpreter is to
    run Ruby code, and say when it can't stating the immediate reason why.

    > 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.


    I'll repeat that I haven't seen evidence that this class of errors is
    diagnosed with the level of detail you'd like in a language with a
    computation model similar to Ruby from you.


    David Vallner


    --------------enigD62F977933D999B110F27AC5
    Content-Type: application/pgp-signature; name="signature.asc"
    Content-Description: OpenPGP digital signature
    Content-Disposition: attachment; filename="signature.asc"

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (MingW32)

    iD8DBQFFZM9Ey6MhrS8astoRAiwTAJ9+f1EyGMSC+E1p5dzd1Z8iAQAWXQCfYD/i
    YF7xu02eYAmP7jdagl5SToU=
    =RSPk
    -----END PGP SIGNATURE-----

    --------------enigD62F977933D999B110F27AC5--
    David Vallner, Nov 22, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Han Holl
    Replies:
    2
    Views:
    100
    Yukihiro Matsumoto
    Sep 1, 2003
  2. Trevor Wennblom
    Replies:
    13
    Views:
    214
    Esteban Manchado Velázquez
    Jan 16, 2005
  3. anne001
    Replies:
    1
    Views:
    402
  4. ngoc
    Replies:
    3
    Views:
    86
  5. Michael Fellinger
    Replies:
    3
    Views:
    151
    Michael Fellinger
    Dec 27, 2007
Loading...

Share This Page