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

FailureReport's exit() causes exception backtrace to not get output #58

Open
cgriego opened this issue Aug 22, 2010 · 1 comment
Open
Labels

Comments

@cgriego
Copy link

cgriego commented Aug 22, 2010

Given a project using --failure-threshold and an uncaught exception being raised (one outside of a test/spec), some/all of the tests/specs will fail to execute, resulting in threshold not being met. At this point, the FailureReport formatter will kick in, notice the coverage failure, and call exit(1), to ensure an error exit code, which raises a SystemExit. The SystemExit causes the original exception's backtrace to not get output.

This is affecting my team's ability to diagnose test failures that happen as a result of an initialization failure (database connection problem, configuration problem, etc.) because the underlying exception isn't visible, but instead we simply see a 0% coverage error.

I'm unsure what would be the best solution to this would be, but here are two options that seemed to work when tried. One is not to raise SystemExit when an exception has already been raised using exit(1) if $__rcov_exit_exception.nil?. The exit code will still be non-zero because of the original exception. Another is to register the SystemExit as an after_exit hook using after_exit { exit(1) }.

@abedra
Copy link
Contributor

abedra commented Jan 23, 2012

This is an interesting case. I agree that this is an issue. The initial reason for introducing the nonzero exit is for CI builds that look for non zero exits to trigger a failure in the build. I will take a closer look here and see what the best course of action is. I don't think the after_exit hook is the best option because that has the potential to be overridden or ignored. The conditional exit looks like it might be appropriate though.

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