Should a debugger treat exit(1) as an uncaught exception?

Python Help
1

There is a popular VS Code extension called debugpy with 36,761,718 installs. This extensions treats exit(1) as an uncaught exceptions and halts debugging.

There is a discussion going on about this at the debugpy repository, whether exit(1) should halt the debugger or not. I’m picking out the first and last post in the discussion:

Arguments against halting:

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 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.

Arguments for halting:

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.

I am curious what the Python developers thought when they designed the exception hierarchy and wrote the documentation. And if debuggers had any influence on these decisions, or not.

2

I can see advantages to halting at a non-zero exit code. By definition that means that something went wrong and it could be beneficial to examine the state at that time.

3

The status of a process on exit does can mean many things (wrong being only one posibility).
It could mean the code of the program failed to run as intended.
It could mean that the code worked as designed and needs to tell the call that something interesting happened.

For example the unix test command returns 0 if the test is true and 1 if the test is not true. The test command was not “wrong”.

4

I think the debugpy devs made a justifiable conservative design choice to catch everything. However I don’t know either, why debugging is then halted, at what in many cases is precisely the point of interest, even if the program has ended. Perhaps it would be a good extra feature, to allow a config setting to toggle this off?

Does it halt if the program explicitly raises a custom exception too? What does pdb do?

5

Fair enough. Non-zero means “exited with error” and the error may not indicate something went wrong.