Check for custom_exceptions only once #1742
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Is there an easy way to test? |
|
Good point, I've added a test. |
|
Test results for commit 67f2d22 merged into master
Not available for testing: python2.6, python3.1 |
minrk
added a commit
that referenced
this pull request
May 31, 2012
Check for custom_exceptions only once We already catch custom exceptions in run_code and call the custom handler, but we were checking for them again in showtraceback. This just removes the second check, so custom exception handlers can safely call showtraceback().
mattvonrocketstein
pushed a commit
to mattvonrocketstein/ipython
that referenced
this pull request
Nov 3, 2014
Check for custom_exceptions only once We already catch custom exceptions in run_code and call the custom handler, but we were checking for them again in showtraceback. This just removes the second check, so custom exception handlers can safely call showtraceback().
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As reported on the mailing list, setting a custom exception handler which does something before displaying the default traceback leads to unexpected recursion.
We already catch custom exceptions in
run_codeand call the custom handler, but we were checking for them again inshowtraceback. This just removes the second check, so custom exception handlers can safely call showtraceback().This is a slight API change - previously, calling showtraceback would dispatch the custom exception handler if the exception type exactly matched one of those specified (not a subclass). Now it will ignore custom exception handlers. However, I think this change is more intuitive (Min's example code on the mailing list assumed it would work this way), and the use case is reasonable.
I'll look at adding a test for this later.