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

Add option to raise exception on internal errors #5768

Merged
merged 3 commits into from Oct 12, 2018

Conversation

Projects
None yet
2 participants
@TV4Fun
Copy link
Contributor

TV4Fun commented Oct 11, 2018

For using external debugging tools like PyCharm, the most helpful thing
to do on an internal error is to just raise an exception, rather than
printing a stacktrace or dropping to PDB.

TV4Fun added some commits Oct 11, 2018

Add option to raise exception on internal errors
For using external debugging tools like PyCharm, the most helpful thing
to do on an internal error is to just raise an exception, rather than
printing a stacktrace or dropping to PDB.
@gvanrossum

This comment has been minimized.

Copy link
Member

gvanrossum commented Oct 11, 2018

I guess it's arguable what's the right thing to do though. What does your caller want to do with the exception, other than print a traceback?

OTOH maybe the code that calls report_internal_error() should check this flag instead, and just call raise (to re-raise the original exception) so it can be caught and debugged in its full glory. I'd use that occasionally when developing mypy.

@TV4Fun

This comment has been minimized.

Copy link
Contributor

TV4Fun commented Oct 11, 2018

@gvanrossum report_internal_error() is called in 5 different places in Mypy from different places that can catch exceptions, and it seems like it would be bad coding practice to require all of them to include exactly the same check, when we already have report_internal_error() specifically to handle internal exceptions in accordance with the user's preference. Re-raising the original exception as this does preserves the stacktrace of the context that originally produced the exception, which is generally what we want for debugging. My particular use case in this is using PyCharm to debug changes to Mypy. Pycharm will break on exceptions and show you the exact location in the code as well as the values of all variables in every scope, which is quite helpful. Printing a stacktrace does not usually give enough useful information by itself to check an error, and while I'm sure I could probably get this same information from pdb, PyCharm provides a more visual interface, and I am more comfortable with it.

@gvanrossum
Copy link
Member

gvanrossum left a comment

OK, you've convinced me. That use case seems legit.

@gvanrossum gvanrossum merged commit fb1b90e into python:master Oct 12, 2018

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment