Repository navigation
Break debugger on exceptions that aren't handled inside a pytest test #111
Description
When running "Debug Test" from the code edit view, the test output pane shows me pytest's error message when it encounters an uncaught exception, but I would like it to launch a debugger instead. I currently have to insert a try/catch with a breakpoint() otherwise.
I actually feel this should have been requested already but could find neither an issue nor a setting for this...
Activity
int19h commentedon Apr 9, 2020
The problem here is that we're not treating the exception is uncaught. I think this is because it's caught by pytest.
However, pytest is library code, not user code; and we run with
"justMyCode": trueby default. Thus, if the exception escapes to library code with no possibility that it might flow back into user code, we should consider it as unhandled. For example, we can walk the stack and see if there are any frames below pytest that are user code.Fabio Zadrozny (@fabioz), does this sound feasible?
int19h commentedon Apr 9, 2020
Nikolaus Waxweiler (@madig) As a partial workaround, you can try checking "Raised exceptions" in the Breakpoints pane. The downside is that it'll also report exceptions that you throw and then handle in your code.
[-]Debug Test: Launch debugger automatically on uncaught exception[/-][+]Break debugger on exceptions that aren't handled inside a pytest test[/+]fabioz commentedon Apr 9, 2020
I've renamed from my understanding of the request (please correct it if I understood wrong).
Well, the problem is that technically this isn't an uncaught exception (because as Pavel Minaev (@int19h) mentioned, it's caught by pytest)...
I don't think it's feasible to report it as uncaught before actually being uncaught (this isn't the actual semantic of uncaught exceptions and breaking it makes the handling quite tricky)... maybe it'd be possible to have a
test unhandled exceptionwhich reports if the exception is raised when atestmethod exists?karthiknadig commentedon Apr 9, 2020
There is
userUnhandledmode when setting extension breakpoints. I think we could make use of it instead. VS 2017/2019 supports this, and for VSC we could also provide it as an additional checkbox. Currently we translateuserUnhandledtounhandledfor VS.https://microsoft.github.io/debug-adapter-protocol/specification#Types_ExceptionBreakMode
fabioz commentedon Apr 9, 2020
Ok, I'll try to come up with a proper implementation for
userUnhandledas it seems like it'd solve this use case.karthiknadig commentedon Apr 10, 2020
/cc Rich Chiodo (@rchiodo)
jekbradbury commentedon May 19, 2020
Any updates? I find myself wanting this functionality just about every day... 🙂
fabioz commentedon May 19, 2020
Not yet (I have 2 other issues in the queue before getting this one, so, I'd say I'll probably get to it in a couple of weeks).
fabioz commentedon May 27, 2020
Note: I'm starting to take a look at this now.
Handle userUnhandled exception breakpoints. Fixes microsoft#111
Handle userUnhandled exception breakpoints. Fixes microsoft#111
Handle userUnhandled exception breakpoints. Fixes microsoft#111
Handle userUnhandled exception breakpoints. Fixes microsoft#111