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

Exception handling #138

Open
UnkindPartition opened this issue May 5, 2016 · 2 comments
Open

Exception handling #138

UnkindPartition opened this issue May 5, 2016 · 2 comments

Comments

@UnkindPartition
Copy link
Owner

Hey @nomeata. I'm looking at tasty-hunit code in connection with the policy that you proposed. In d1d417c you said that HUnit sas already catching exceptions. But in fact it only catches HUnitFailure exceptions (https://github.com/feuerbach/tasty/blob/master/hunit/Test/Tasty/HUnit.hs#L52). Doesn't that contradict your policy?

On the other hand, catching all the exceptions would interfere with timeout handling code, as explained in the comment. (In fact, your changes to smallcheck & quickcheck probably interfere with it already, I just didn't realize that.)

@nomeata
Copy link
Contributor

nomeata commented May 5, 2016

Hmm; maybe I mis-read the code? Or maybe I was looking at the exception catching code in HUnit, and did not realize you are not using that?

Why exactly would it interfere with timeout-handling? (The comment only says that it interferes, not why.)

@UnkindPartition
Copy link
Owner Author

Because System.Timeout.timeout throws an exception, but will be unable to catch it back. The exception will still abort the computation, but the message will be different.

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

No branches or pull requests

3 participants