Event machine example breaks when an error is raised from an handler
patatepartie opened this issue · comments
When an handler raises an error, it will reject the next promise, but also let the error bubble up the call stack.
When using the example EM Promise subclass in an RSpec spec, this will generate weird behaviors:
- if only 1 test exists, it will pass with the message 'Empty test suite.'
- if other tests exist, we'll get the following trace in all tests:
RuntimeError: can't modify frozen object
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/example.rb:274:in `extend_object'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/example.rb:274:in `extend'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/example.rb:274:in `finish'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/example.rb:139:in `run'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/example_group.rb:390:in `block in run_examples'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/example_group.rb:386:in `map'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/example_group.rb:386:in `run_examples'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/example_group.rb:371:in `run'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/command_line.rb:28:in `block (2 levels) in run'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/command_line.rb:28:in `map'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/command_line.rb:28:in `block in run'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/reporter.rb:34:in `report'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/command_line.rb:25:in `run'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/runner.rb:80:in `run'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/runner.rb:17:in `block in autorun'This happens will all rspec versions I tested.
I suggest explaining that in the docs, I almost gave up on the library because I thought it was a bug in it.
Thank for it, btw, I like the API and being able to use any 'scheduler'.
Hey, thanks for reporting this! Getting to this a bit late because I didn't know that I have to watch my own repositories in order to get notifications.
I'm at CouchHack right now, but I'll look into the issue today.
It looks like you need to update RSpec to at least 2.14.6. Until that version, RSpec used to extend exceptions raised by your examples. Promise.rb freezes arguments to fulfill/reject, so whenever you sync on a rejected response, the (frozen) rejection reason will be re-raised, RSpec tries to extend it and blows up.
This is the offending code: https://github.com/rspec/rspec-core/blob/v2.13.1/lib/rspec/core/example.rb#L274
And I fixed it here: rspec/rspec-core#1106
@patatepartie I just removed the freezing of value and reason: 74da6e9 (have a look at the commit message for the reasoning)
In your case it's RSpec's fault though, it shouldn't freeze exceptions :) I'll release 0.5.0 probably tomorrow, once I finish the work on the backtrace branch. Until then you can try updating RSpec, as I explained above.
Hi Lars,
Upgrading to the latest rspec worked as you said. I didn't do it previously
because it is not supported by my IDE, Rubymine.
The fix also worked.
Thank you!
On Mon, Dec 16, 2013 at 7:39 AM, Lars Gierth notifications@github.comwrote:
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1
.