[LRUG] To debug the impossible bug

[Viktor Tron]

Muz, explicit delegation gives you runtime error

ruby-1.9.2-p180 :078 > class T; delegate :t, :to => :nilf; def nilf; end  
end
  => nil
ruby-1.9.2-p180 :079 > @q=T.new
  => #<T:0x9887800>
ruby-1.9.2-p180 :080 > case when @q then @q.t end
RuntimeError: T#t delegated to nilf.t, but nilf is nil: #<T:0x9887800>

although yes can think of a few convoluted ways to get the impossible bug  
for lols:

ruby-1.9.2-p180 :066 > class T; def self.t; @t.t end end
  => nil
ruby-1.9.2-p180 :067 > @q=T
  => T
ruby-1.9.2-p180 :068 > case when @q then @q.t end
NoMethodError: undefined method `t' for nil:NilClass


ruby-1.9.2-p180 :069 > class T; def self.t; raise(NoMethodError,"undefined  
method `t' for nil:NilClass") end end
  => nil
ruby-1.9.2-p180 :070 > @q=T
  => T
ruby-1.9.2-p180 :071 > case when @q then @q.t end
NoMethodError: undefined method `t' for nil:NilClass
         from (irb):69:in `t'


but seriously Tats got a point, look at the backtrace to make sure  
NoMethodError is coming from
the case statement itself, not from inside the  
WhateverQuestionClass#background method.

hth vik


On Wed, 03 Aug 2011 13:21:21 +0100, Murray Steele  
<murray.steele at gmail.com> wrote:

> Hi Simon,
>
> I don't suppose that the background of a question is a delegate method?
>  E.g. the question is not nil, so the case fires that branch, but the  
> object
> that the question delegates background to *is* nil so you get the
> NoMethodError.
>
> Muz
>
> On 3 August 2011 12:59, Tatsuya Ono <ononoma at gmail.com> wrote:
>
>> Hi Simon,
>>
>> It is a quite interesting problem. What I suspected were ...
>>
>> 1) Multithread issue
>> Daniel pointed out already and you seemed confident that it is not the
>> issue.
>>
>> 2) Error happened different place.
>> e.g.
>> class Question
>>   def background
>>     return @something.background # <= NoMethod error @something is nil  
>> here
>>   end
>> end
>>
>> I know that unless you are bit careless, you wouldn't miss the  
>> backtrace.
>> However there might be a situation stack trace is not clear when the
>> background method is implemented with some kinds of meta programming  
>> trick.
>>
>> I could not get any other idea apart from abobe for now. I would output  
>> log
>> to get more information.
>>
>> e.g.
>>
>> def page_description
>>   dump = @question.inspect
>>   begin
>>    case
>>      when @question then @question.background            # exception  
>> raised
>> here
>>      <snip other cases>
>>    end
>>   rescue NoMethodError=>e
>>     logger.info "Gotcha!!!!"
>>     logger.info "BEFORE: #{dump}
>>     logger.info "AFTER: #{@question.inspect}"
>>     logger.info "backtrace: #{e.backtrace}"
>>     logger.info "exception: #{e.message}"
>>     raise e
>>   end
>> end
>>
>> Maybe we have to wait another one week, though, I am interested in what  
>> it
>> tells.
>>
>>
>> Tatsuya
>> twitter.com/ono
>>
>> On 3 August 2011 12:28, Jordi Noguera Leon  
>> <jordinoguera83 at gmail.com>wrote:
>>
>>> I'd rather use:
>>>
>>> def some_other_method
>>>   return foo.whatever if foo
>>>   return bar.whatever if bar
>>>   "some message"
>>> end
>>>
>>>
>>> On 3 August 2011 12:23, Viktor Tron <viktor.tron at gmail.com> wrote:
>>>
>>>> yes with no value, case becomes a concise way of writing if .. elsif  
>>>> ..
>>>> elsif conditionals
>>>> since simon's code is of this type, the bug he gets is a bug you  
>>>> expect
>>>> with the
>>>> case nil variant unless somewhere case is redefined to fall back to  
>>>> nil
>>>> with no args
>>>> Simon, is this not the 'case'? :)
>>>>
>>>> a little simplified irb for you:
>>>>
>>>> ruby-1.9.2-p180 :001 > case nil when nil then true else false end
>>>>  => true
>>>> ruby-1.9.2-p180 :002 > case when nil then true else false end
>>>>  => false
>>>>
>>>>
>>>>
>>>> On Wed, 03 Aug 2011 12:15:38 +0100, Tom Stuart <tom at therye.org> wrote:
>>>>
>>>>
>>>>> On 3 Aug 2011, at 12:12, Matthew Rudy Jacobs wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> On 3 August 2011 12:09, Tom Stuart <tom at therye.org> wrote:
>>>>>>
>>>>>> See page 141 of the pickaxe for this use of case.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>> Please enlighten me, then.
>>>>>> What's the usecase?
>>>>>>
>>>>>> Have never seen this done.
>>>>>>
>>>>>
>>>>> According to the Pickaxe '[this] form is fairly close to a series of  
>>>>> if
>>>>> statements; it lets you list a series of conditions and execute a  
>>>>> statement
>>>>> corresponding to the first one that's true."
>>>>>
>>>>> The code example there is:
>>>>>
>>>>> case
>>>>> when song.name == "Misty"
>>>>>  puts "Not again!"
>>>>> when song.duration > 120
>>>>>  puts "Too long!"
>>>>> when Time.now.hour > 21
>>>>>  puts "It's too late"
>>>>> else
>>>>>  song.play
>>>>> end
>>>>>
>>>>> It's pretty ugly, but it's valid Ruby and has nothing to do with the
>>>>> more usual use of case for comparison with === against multiple  
>>>>> values.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Tom
>>>>>
>>>>>
>>>>
>>>> --
>>>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>>>>
>>>> ______________________________**_________________
>>>> Chat mailing list
>>>> Chat at lists.lrug.org
>>>> http://lists.lrug.org/**listinfo.cgi/chat-lrug.org<http://lists.lrug.org/listinfo.cgi/chat-lrug.org>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Chat mailing list
>>> Chat at lists.lrug.org
>>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>>
>>>
>>
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
>>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/