Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

do_not_allow usability issue with "rescue" #40

Open
wincent opened this issue Jul 1, 2010 · 2 comments
Open

do_not_allow usability issue with "rescue" #40

wincent opened this issue Jul 1, 2010 · 2 comments
Labels

Comments

@wincent
Copy link
Contributor

wincent commented Jul 1, 2010

I'm currently testing a method which uses "rescue" like this:

def foo
    do_something
rescue Exception => e
    log(e) # log the exception and swallow it
end

In one of my specs I want to use "do_not_allow" to confirm that something doesn't happen:

it 'should not call thingy' do
   do_not_allow(Target).thingy
   foo
end

The trouble is, that if "thingy" is called, RR will immediately throw an RR::Errors::TimesCalledError, which will be swallowed up by the "rescue" in the method being tested and never seen by RSpec.

Would it be possible to change the behavior of "do_not_allow", then, to defer evaluation in the same way that "mock" doesn't actually get verified until the end of the RSpec example?

For the meantime, the workaround is to change my "rescue" handler to explicitly check for RR exceptions and propagate them, but this is a bit ugly because it contaminates the code being tested with knowledge about the testing tools:

rescue Exception => e
  raise e if e.kind_of?(RR::Errors::RRError)
  log(e) # and swallow
end

Cheers,
Wincent

@btakita
Copy link
Owner

btakita commented Jul 2, 2010

Thanks for the report. Ideally, I would like this operation to fail fast. Would a throw work instead?

@wincent
Copy link
Contributor Author

wincent commented Jul 2, 2010

I imagine so, because you could throw a very specific symbol which no application will catch "by accident" in the way that we're seeing here (rescuing "Exception" and catching an RR-specific subclass of it).

Cheers,
Wincent

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants