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
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
