rspec users - Mar 2009 - what has RSpec got against stack traces?

Here''s an error message. The details are not important (beyond to_xml
on a
virtual AR database via fixture_dependencies). I know how to work the actual 
problem.

   NoMethodError in ''BlogMindMap should create XML''
   undefined method `macro'' for nil:NilClass
   spec/blog_mind_map_spec.rb:192:
   spec/blog_mind_map_spec.rb:11:

Line 192 contains neither a stray nil nor a method ''macro''.

The question is why did RSpec throw away the backtrace? Am I the first person in
history to hit a programming error inside RSpec??

-- 
   Phlip

Phlip wrote:
> Here''s an error message. The details are not important (beyond
to_xml
> on a virtual AR database via fixture_dependencies). I know how to work 
> the actual problem.
>
>   NoMethodError in ''BlogMindMap should create XML''
>   undefined method `macro'' for nil:NilClass
>   spec/blog_mind_map_spec.rb:192:
>   spec/blog_mind_map_spec.rb:11:
>
> Line 192 contains neither a stray nil nor a method
''macro''.
>
> The question is why did RSpec throw away the backtrace? Am I the first 
> person in history to hit a programming error inside RSpec??
>
Nope, but this probably isn''t one of them. 

Can you post your spec and any relevant code?

Scott

>> The question is why did RSpec throw away the backtrace? Am I the first 
>> person in history to hit a programming error inside RSpec??
> Nope, but this probably isn''t one of them.
I said it wrong. The complete venting goes "Am I the first person in
history to
use RSpec, and then hit a programming error?" The comma , makes the phrases
non-restrictive.

And I don''t give a darn if RSpec itself had a programming error, so
long as it
traced it!
> Can you post your spec and any relevant code?
Nope. Try 1/0 inside a sub-method - you won''t get a stack trace to it,
right?

2009-03-06 22:32, Phlip:
> Line 192 contains neither a stray nil nor a method
''macro''.
So what exactly _is_ there?  Do you know that particular line causes
(or noes not cause) the error?  

In situations like this I usually pop to debugger right before the
problematic line and then poke around (eval the problematic expression
in smaller parts, move up in the call stack and look for anomalies) to
find out whats up.
> The question is why did RSpec throw away the backtrace?
How do you know it did that?  From the information you gave us, I
can''t deduce that.  ...and maybe I just suck at deduction.  ;)
> Am I the first person in history to hit a programming error inside
> RSpec??
What makes you suspect you are?

-- 
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/

Phlip wrote:
>>> The question is why did RSpec throw away the backtrace? Am I the 
>>> first person in history to hit a programming error inside RSpec??
>
>> Nope, but this probably isn''t one of them.
>
> I said it wrong. The complete venting goes "Am I the first person in 
> history to use RSpec, and then hit a programming error?" The comma , 
> makes the phrases non-restrictive.
>
> And I don''t give a darn if RSpec itself had a programming error,
so
> long as it traced it!
I don''t think it rewrites the callstack in anyway.  More than likely
the
object you are calling the method on is nil.  If you can''t figure it
out
just by looking at the spec, I''d suggest running the debugger right 
before the line the line that fails.  Insert this into your spec:

it "...." do
  ...
  require ''rubygems''; require ''ruby-debug'';
debugger
   ... # the failing line
end

Run your specs, and you should be confronted by the debugger - this will 
allow you live introspection of the process and results right before 
they happen.  ( search for a ruby-debug guide out there on the interwebs 
if you''ve never used it before).

If you are correct, you should be able to show (via the debugger, by 
stepping into any relevant functions) that the stack is being rewritten.
>
>> Can you post your spec and any relevant code?
>
> Nope. Try 1/0 inside a sub-method - you won''t get a stack trace to
it,
> right?
Usually it does:

 >> def foo
 >>   1/0
 >>   end
=> nil
 >> def bar
 >>   foo
 >>   end
=> nil
 >> bar
ZeroDivisionError: divided by 0
    from (irb):43:in `/''
    from (irb):43:in `foo''
    from (irb):46:in `bar''
    from (irb):48


Hope that helps,

Scott

>> Nope. Try 1/0 inside a sub-method - you won''t get a stack
trace to it,
>> right?
> Usually it does:
> 
>  >> def foo
>  >>   1/0
>  >>   end
> => nil
>  >> def bar
>  >>   foo
>  >>   end
> => nil
>  >> bar
> ZeroDivisionError: divided by 0
>    from (irb):43:in `/''
>    from (irb):43:in `foo''
>    from (irb):46:in `bar''
>    from (irb):48
I don''t see any RSpec above that in the call stack.

Tero Tilus wrote:
>> Line 192 contains neither a stray nil nor a method
''macro''.
> 
> So what exactly _is_ there?  Do you know that particular line causes
> (or noes not cause) the error?  
Test::Unit::TestCase said the error was ~20 layers deeper - but exactly below 
the same to_xml() call as RSpec indicated. RSpec threw the stack trace away.

Please please please focus: Nobody is asking how to debug, or how to call 
to_xml() correctly. (The problem turned out to be :include => :authors
instead
of :include => :author, where the belongs_to used :author singular. Big
deal!)

def really_div_by_zero
     1/0
   end

   def div_by_zero
     really_div_by_zero
   end

   it ''should trace my stack'' do
     div_by_zero
   end

And that hits the correct line:

ZeroDivisionError in ''Whatever should trace my stack''
divided by 0
spec/blog_mind_map_spec.rb:192:in `/''
spec/blog_mind_map_spec.rb:192:in `really_div_by_zero''
spec/blog_mind_map_spec.rb:196:in `div_by_zero''
spec/blog_mind_map_spec.rb:200:
spec/blog_mind_map_spec.rb:11:

So the question becomes: Why do we sometimes get the correct stack trace and 
sometimes we don''t?

On Sat, Mar 7, 2009 at 8:25 AM, Scott Taylor <scott at railsnewbie.com>
wrote:
> Phlip wrote:
>>>>
>>>> The question is why did RSpec throw away the backtrace? Am I
the first
>>>> person in history to hit a programming error inside RSpec??
script/spec -b /path/to/spec.rb will give a full backtrace. You can
also add --backtrace to your spec.opts.

Cheers,

Chris

Phlip wrote:
> Tero Tilus wrote:
>
>>> Line 192 contains neither a stray nil nor a method
''macro''.
>>
>> So what exactly _is_ there?  Do you know that particular line causes
>> (or noes not cause) the error?  
>
> Test::Unit::TestCase said the error was ~20 layers deeper - but 
> exactly below the same to_xml() call as RSpec indicated. RSpec threw 
> the stack trace away.
>
> Please please please focus: Nobody is asking how to debug, or how to 
> call to_xml() correctly. (The problem turned out to be :include => 
> :authors instead of :include => :author, where the belongs_to used 
> :author singular. Big deal!)
Go and file a bug report then, but if you only give this level of 
detail, the bug will never get fixed.

Even if you can''t post code (because it''s closed-source or
what
have-you),  usually you can at least post a spec.  Please please please 
focus: We can''t read your specs nor your code, and without that we are 
poking around in the dark.

Scott

2009-03-07 01:12, Phlip:
> Test::Unit::TestCase said the error was ~20 layers deeper - but
> exactly below the same to_xml() call as RSpec indicated. RSpec threw
> the stack trace away.
You could have told that right away.  :-/

It seems I cant reproduce the trace mangling.  Do have steps to
reproduce?
> Please please please focus: Nobody is asking how to debug
We are trying.  You did not tell you did debugging, so we told you
to try it, because it is usually the first step.  Please, don''t take
it personally that we might not all know you and your debug-fu.  ;)

-- 
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/

2009-03-07 01:17, Phlip:
> So the question becomes: Why do we sometimes get the correct stack
> trace and sometimes we don''t?
What do you mean by "correct"?  To my knowledge you havent posted any
single somehow incorrect stack trace.  If you by "correct" mean
"complete", I dare to ask if you do script/spec -b or something else?

-- 
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/

> script/spec -b /path/to/spec.rb will give a full backtrace. You can
> also add --backtrace to your spec.opts.
> 
> Cheers,
> 
> Chris
Yay! txkbye!

Scott Taylor wrote:
> Go and file a bug report then, but if you only give this level of 
> detail, the bug will never get fixed.
I am not reporting any bug in RSpec. Read the Subject line.

I think I know why RSpec has an option (-b) to turn off incomplete stack traces.
The various Ruby editors have feeble support for Fault Navigation. At fault 
time, I would like keystrokes that move, optionally, to each line that threw an 
error, or each line in project code on the stack trace above an error, or even 
each line in library code above an error.

So RSpec, assuming its editor cannot support that simple feature, simply picks 
the short trace, to emphasize its own .should lines that faulted.

(Many''s the time we have squinted at a humongoid stack trace from
Rails, trying
to see the difference between all the library code and our own lines!)

-- 
   Phlip
  
http://www.oreillynet.com/onlamp/blog/2008/05/dynamic_languages_vs_editors.html

On Mar 7, 2009, at 5:49 AM, Phlip wrote:
> Scott Taylor wrote:
>
>> Go and file a bug report then, but if you only give this level of  
>> detail, the bug will never get fixed.
>
> I am not reporting any bug in RSpec. Read the Subject line.
>
> I think I know why RSpec has an option (-b) to turn off incomplete  
> stack traces. The various Ruby editors have feeble support for Fault  
> Navigation. At fault time, I would like keystrokes that move,  
> optionally, to each line that threw an error, or each line in  
> project code on the stack trace above an error, or even each line in  
> library code above an error.
RSpec modifies the stack trace, filtering out internal lines to reduce  
noise.  It''s possible that it''s filtering too much.

Anyway, as Scott has said numerous times, there''s not really anything  
we can do if you''re not interested in helping us help you.  Besides  
the suggestion to use the -b switch, anyway.

Pat