Exceptions that inherit from BaseException should not be treated as Uncaught Exceptions

[danielniccoli]

Before creating a new issue, please check the FAQ to see if your question is answered there.

Environment data

• debugpy version: 1.8.1
• OS and version: Windows 11
• Python version: 3.11
• Using VS Code or Visual Studio: VS Code

Actual behavior

exit(1) halts the debugging session due to an "uncaught exception"

Expected behavior

The program program should exit without the debugger halting.

Exceptions that inherit from exception.BaseException should not fall under the category of "uncaught exceptions", since they are "technically not an error"¹.

exception.BaseException

The base class for all built-in exceptions. It is not meant to be directly inherited by user-defined classes (for that, use Exception).

https://docs.python.org/3/library/exceptions.html#BaseException

One of these exceptions is exception.SystemExit, which is called when calling exit(1).

exception SystemExit

This exception is raised by the sys.exit() function. It inherits from BaseException instead of Exception so that it is not accidentally caught by code that catches Exception. This allows the exception to properly propagate up and cause the interpreter to exit. When it is not handled, the Python interpreter exits; no stack traceback is printed.

https://docs.python.org/3/library/exceptions.html#SystemExit

There are only three other Exceptions that inherit from exception.BaseException, not counting exception.Exception, which does fall under the category of "Uncaught Exceptions":

BaseException
 ├── BaseExceptionGroup
 ├── GeneratorExit
 ├── KeyboardInterrupt
 ├── SystemExit
 └── Exception

https://docs.python.org/3/library/exceptions.html#exception-hierarchy

exception KeyboardInterrupt

Raised when the user hits the interrupt key (normally Control-C or Delete). During execution, a check for interrupts is made regularly. The exception inherits from BaseException so as to not be accidentally caught by code that catches Exception and thus prevent the interpreter from exiting.

exception GeneratorExit

Raised when a generator or coroutine is closed; see generator.close() and coroutine.close(). It directly inherits from BaseException instead of Exception since it is technically not an error.

Footnotes

1. https://docs.python.org/3/library/exceptions.html#GeneratorExit ↩

[rchiodo]

Transferring to dicussions for up votes

[indigane]

I can imagine use cases where one would want the debugger to pause on non-zero SystemExit, as those are usually errors.

Solely based on that I would be in favor of a new setting.

I haven't done the research though. I only have my own use case which is debugging tests where I explicitly don't want the debugger to pause every time the test-run ends with failures. And again if there are better solutions to solving that specific case I'm open to ideas.

[int19h]

This behavior existed all the way back to the original ptvsd even.

That said, given that "breakOnSystemExitZero" is already a launch.json option, it would be nice to make this more generic and to allow explicitly specifying ranges of error codes. Then one could disable this behavior entirely by not specifying any, e.g.:

"breakOnSystemExit": [0, 2, {"from": 3, "to": 100}];

"breakOnSystemExit": [];  // never break

As it is, this is already special-cased for some libraries. E.g. Django uses exitcode 3 to indicate reloading, and so pydevd doesn't break on SystemExit(3) if "django":true is set. This is hardcoded, though.

[indigane]

This? https://github.com/fabioz/PyDev.Debugger/blob/0e0d434/_pydevd_bundle/pydevd_process_net_command_json.py#L432-L435

Weird that there is such a special case.

Using these terms I would want a special case to ignore this for pytest:

https://github.com/pytest-dev/pytest/blob/0d96a5bf9059e51324ac24ec24d68af1c35db6d8/_pytest/main.py#L28

because the use case for the debugger with pytest is to pause during the tests, not after the tests when pytest is exiting every time there are any failed tests. There is nothing to debug during the exit, the tests are already long gone.

I think more special cases is a bad idea but do you think an issue should be opened @ pydevd for this use case?

[danielniccoli]

The user wanted the exact behavior we have

@rchiodo

A debugger should first and foremost conform to the programming language it's written for. And the docs are clear about these exceptions being only for internal use, and that a debugger should not halt execution. It is that, which gives any questions a foundation for discussion. Debugpy violates that, leading to where we are: an argument, rather than a discussion… and hard-coded workarounds for behaviour in Django (thanks @int19h).

It also misleads people's expectations. The comment you linked (#489 (comment)) is a perfect example of that.

The expected behavior in default should be: […] sys.exit(n) for nonzero n breaks

What is this expectation based on? I don't say that because I want to invalidate his opinion. But as everybody has a different opinion, the best option for a baseline is to stick to the documented behaviour first, and then give people the option to change this behaviour so it suits their needs.

– or you disregard all of that, in which case all the people that know what should happen, have their expectations failed by debugpy. And from the rest of the people, half of them have their expectations also failed. I don't think this is what anybody wants.

I have one more point.

I can imagine use cases where one would want the debugger to pause on non-zero SystemExit, as those are usually errors.

@indigane

exit(1) is deliberate. It does indicate an error, but it does not indicate an exception. This should throw an uncaught exception, which should be handled by debugpy:

./test.py 1 0

import sys

n1 = float(sys.argv[1])  # n1 = 1
n2 = float(sys.argv[2])  # n2 = 0

print(n1/n2)

This should not

./test.py 1 0

import sys

n1 = float(sys.argv[1])
n2 = float(sys.argv[2])

try:
    print(n1/n2)
except ZeroDivisionError:
    exit(1)

In conclusion, the way it is currently implemented is not conform to the docs and imposes truly unexpected behaviour upon the developer that cannot be altered. Fixing this behaviour would solve so many problems, would allow you to remove hardcoded workarounds from your code base and would result in a package that respects the Python specs.

And if it's important to you (which I can see) implement a configuration option that let's a developers alter debugpy's behaviour, if they want debugpy to halt on exit(), as @int19h suggested.

[int19h]

The Python documentation doesn't say anything about how debuggers should behave, only about how user code should behave. It talks about "catching" exceptions, but debugger isn't doing that - it is reporting them. Thus this is not an issue of conformance. Debugger is reporting exceptions, and SystemExit is an exception. Whether to exclude it or not by default should be based on whether it makes sense for most scenarios or not. Given that a non-zero exit code is the standard way of reporting errors to the OS on all major platforms, thus it makes sense that it is reported by default.

In general, debuggers are inherently "meta" wrt user code and what it does, and it is, in fact, not uncommon for them to expose things that are normally under the hood. For example, they will show you private slots of an object.