[rspec-users] what has RSpec got against stack traces?

Scott Taylor scott at railsnewbie.com
Sat Mar 7 03:25:54 EST 2009

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

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,


More information about the rspec-users mailing list