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

Better exception handling #8

Open
0152la opened this issue Jul 15, 2016 · 6 comments
Open

Better exception handling #8

0152la opened this issue Jul 15, 2016 · 6 comments
Assignees

Comments

@0152la
Copy link
Collaborator

0152la commented Jul 15, 2016

Rather than throwing an exception in the CfiDriver, should gather all instances of no produced assertions and report them at the end.

@rsinha rsinha assigned rsinha and 0152la and unassigned rsinha Jul 25, 2016
@rsinha
Copy link
Member

rsinha commented Jul 25, 2016

I think we resolved this last week, right?

@0152la
Copy link
Collaborator Author

0152la commented Jul 26, 2016

I did something briefly on it, just capturing and recording exceptions thrown by the CfiVerifier when executing CfiDriver. I think it's worth having a look and doing something more sophisticated.

@0152la
Copy link
Collaborator Author

0152la commented Jul 27, 2016

Added some more comprehensive exception logging in commit 1bdbb65. Maybe revisit in the future?

@0152la 0152la closed this as completed Jul 27, 2016
@0152la
Copy link
Collaborator Author

0152la commented Jul 27, 2016

Nevermind, apparently the "try..catch" blocks in the CfiDriver which calls the other executables do not actually catch the thrown exception by the process.

@0152la 0152la reopened this Jul 27, 2016
@rsinha
Copy link
Member

rsinha commented Aug 30, 2016

Do you think we need to improve exception handling now? Or should we close this?

@0152la
Copy link
Collaborator Author

0152la commented Aug 31, 2016

It's the same status as before: there is no exception handling. The subprocesses do not throw exception as they "successfully" terminate, albeit throwing an exception. Thus, the "try...catch" blocks around the subprocess calls are dead code.

For the moment, I didn't see any crashes in recent experiments, which means we could leave it be. However, for the future, I think this should be taken into consideration.

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

No branches or pull requests

2 participants