[LRUG] To debug the impossible bug

Wed Aug 3 04:05:17 PDT 2011

Hi Simon.

In your code snippet I want you to think about what it means.

case
when @something
  *do something*
end

now,
you should look at how case statements should work

normally

case something
when "some value"
  *do something*
end

In other words;

   - I want to look at cases of a particular value
   - "when its A do this"
   - "when its B do this"
   - "else do this"

I didn't think "case()" was defined
but my guess is that it means "case nil"

so effectively you're saying;

"when nil is @question"?
and in the case it fails
its because @question is exactly nil.

I dont know the rest of the case statement
but I suggest you should write some test cases around it.

It seems like you're expecting the "when" to function like an if.

On 3 August 2011 11:57, Simon Coffey <simon at tribesports.com> wrote:

> Hi LRUG,
>
> Apologies for posting a bug to the list, but it's weird enough that I
> hope it might be interesting (indeed it appears to be logically
> impossible). It's got me completely stumped, so any thoughts would be
> gratefully received.
>
> We're getting very occasional (~1 per week) exceptions out of one of
> our helper methods in our app (Rails 3.0.3, ruby 1.9.2-p180). For
> example, from the following line of code...
>
>  def page_description
>    case
>    when @question then @question.background            # exception raised
> here
>    <snip other cases>
>    end
>  end
>
> ... we saw "NoMethodError: undefined method `background' for
> nil:NilClass". (The full method can be seen here:
> https://gist.github.com/1120170 )
>
> That's logically impossible, right? @question is clearly nil, as shown
> by the exception. But @question is also clearly not nil, otherwise how
> on earth would that case fire?
>
> Other rules in this case statement are also causing exceptions, but
> with inexplicable things apparently stored in the instance variables.
> For example, we've seen "NoMethodError: undefined method `bio' for
> #<Lead:0xdbc31a0>" from line #6 in the gist, despite the @user
> instance variable only ever being assigned an instance of User, not
> Lead. Another time @user appeared to contain a Hash. Other instance
> variables have contained controller instances.
>
> This only seems to be happening in the #page_description method, which
> is used at the top of the <head> section of our layouts. As such, for
> any given render pass it will always be the first call to access the
> controller instance variables.
>
> It looks to me like our instance variables are somehow getting
> corrupted, but I can't for the life of me see how this would happen.
> Unfortunately it happens only on production, and has so far resisted
> being reproduced, so we have no ability to get further info out of the
> debugger.
>
> Has anyone seen anything like this before? Undying gratitude / a beer
> to anyone who has any bright ideas...
>
> Cheers,
> Simon
>
> --
> Simon Coffey
> Developer, Tribesports
>
> e: simon at tribesports.com
> m: 07960 004 857
> p: Unit 104, Cremer Business Centre, 37 Cremer Street, London, E2 8HD
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20110803/fb935ecc/attachment-0003.html>