-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Retain execution context under handled exception #11512
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
Comments
Can you inspect the |
Perhaps, but how do I get a handle on that exception instance? In the SO post, OP points out that
I'm 90% sure when I attempted this in a real-world case, |
Aha. The issue is with a handled exception: def raise_something():
raise TypeError()
def test_something():
try:
raise_something()
except TypeError:
try:
raise ValueError()
except ValueError:
breakpoint() In this example, after the breakpoint is reached, there's no longer a handle to the
I even tried changing the catch to
Interestingly, the issue seems to be that if I'm handling the exception, I need a statement after the breakpoint in order for that block to still be active. Changing the code to the following allows the breakpoint to expose def raise_something():
raise TypeError()
def test_something():
try:
raise_something()
except TypeError:
try:
raise ValueError()
except ValueError as exc:
breakpoint()
pass Still, it would be nice if |
That behavior appears to be a known issue (python/cpython/#111744). |
What's the problem this feature will solve?
I've got a test similar to the following with a nested exception:
Running the test produces:
I'd like to be able to inspect the stack where
raise_something()
failed. Best I can tell, that context is unreachable.If I use
--pdb
, the code breaks at test.py:9 with theValueError
, but by the time pytest has handled the error,sys.exc_info()
no longer points to the execution context where the failure occurred, but instead may be(None, None, None)
or perhaps an unrelated context like(<class 'AttributeError'>, AttributeError("'PytestPdbWrapper' object has no attribute 'do_sys'"), <traceback object at 0x101f26c40>)
. Therefore, I'm unable to take advantages of techniques to trace to the inner exception stack.Describe the solution you'd like
In the pdb context or in a global variable or in some other way, expose the original unhandled exception context.
The text was updated successfully, but these errors were encountered: