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:

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

Am I the first person in history to hit a programming error inside
RSpec??

What makes you suspect you are?

Phlip wrote:

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:infoo’
from (irb):46:in `bar’
from (irb):48

Hope that helps,

Scott

On Sat, Mar 7, 2009 at 8:25 AM, Scott T. [email protected]
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

Tero T. 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:inreally_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?

Nope. Try 1/0 inside a sub-method - you won’t get a stack trace to it,
right?

bar
ZeroDivisionError: divided by 0
from (irb):43:in /' from (irb):43:infoo’
from (irb):46:in `bar’
from (irb):48

I don’t see any RSpec above that in the call stack.

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

Phlip wrote:

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

Scott T. 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
O'Reilly Media - Technology and Business Training

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!

On Mar 7, 2009, at 5:49 AM, Phlip wrote:

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