-
Notifications
You must be signed in to change notification settings - Fork 63
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
Handle x86 errors more gracefully #1194
Conversation
And provide a template for catching other varieties of exception more consistently.
Is the idea to consolidate all of the exception-handling code into the
Would it make sense to consolidate these bits of functionality into |
I think it would make sense, unless anyone else knows of issues that might come up as a result of that. And there are almost 300 instances of |
That sounds reasonable to me. I suppose the only other thing I might desire from this PR is a test case that demonstrates the new error message, assuming that that is feasible to set up. If that's not feasible, then perhaps showing an example of the new error message in a GitHub comment would suffice. |
Our current test infrastructure would make it a bit difficult to check the error message in this case. It would be nice to set something up to make that straightforward in the future, though. For the moment, here's an example of the error message I get from the code in this PR when I change the
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent. We should open a separate issue about consolidating exception-handler–related code in io
, but beyond that, LGTM.
And provide a template for catching other varieties of exception more
consistently.
Fixes #678.