diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index f8fb64976096..c38e688e591e 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -637,6 +637,7 @@ peps/pep-0756.rst @vstinner peps/pep-0757.rst @vstinner peps/pep-0758.rst @pablogsal @brettcannon peps/pep-0759.rst @warsaw +peps/pep-0760.rst @pablogsal @brettcannon peps/pep-0761.rst @sethmlarson @hugovk # ... peps/pep-0789.rst @njsmith diff --git a/peps/pep-0760.rst b/peps/pep-0760.rst new file mode 100644 index 000000000000..db8a40c8dbc8 --- /dev/null +++ b/peps/pep-0760.rst @@ -0,0 +1,204 @@ +PEP: 760 +Title: No More Bare Excepts +Author: Pablo Galindo , Brett Cannon +Status: Draft +Type: Standards Track +Created: 02-Oct-2024 +Python-Version: 3.14 + + +Abstract +======== + +This PEP proposes disallowing bare ``except:`` clauses in Python's +exception-handling syntax. Currently, Python allows catching all exceptions +with a bare ``except:`` clause, which can lead to overly broad exception +handling and mask important errors. This PEP suggests requiring explicit +exception types in all except clauses, promoting more precise and intentional +error handling. + +Motivation +========== + +The current syntax allows for catching all exceptions with a bare ``except:`` clause: + +.. code-block:: python + + try: + risky_operation() + except: + handle_any_error() + +While this syntax can be convenient for a "catch all" handler, it often leads +to poor coding practices: + +1. It can mask important errors that should be propagated. +2. It makes debugging more difficult by catching and potentially hiding + unexpected exceptions. +3. It goes against the Python principle of explicit over implicit. + +Various linters [1]_ [2]_ [3]_ and style guides (including :pep:`8`) [4]_ [5]_ +[6]_ [7]_ discourage bare ``except`` clauses. + +By requiring explicit exception types, we can encourage more thoughtful and +precise error handling: + +.. code-block:: python + + try: + risky_operation() + except Exception as e: + handle_expected_error(e) + +Another view of this problem is that bare except handlers are ambiguous +regarding the intended handling of terminating exceptions, as the intention +could have been either: + +* Only catch non-terminating exceptions (``except Exception:``). If this was the + intention, using a bare ``except:`` is an outright bug, since that isn't what it + means. +* Catch all exceptions, including terminating ones (``except BaseException:``). + using bare ``except:`` here it is at least correct, but readers need to check + to be sure it isn't an instance of the first case. + +Since both possible intentions have available unambiguous spellings, the +ambiguous form is redundant and that's why we propose to disallow it. + +Rationale +========= + +The decision to disallow bare except clauses is based on the following +considerations: + +1. Requiring specific exception types makes the programmer's intentions clear + and encourages thinking about what exceptions might occur. + +2. Catching only specific exceptions makes identifying and debugging unexpected + errors easier. + +3. Preventing overly broad exception handling reduces the risk of silently + ignoring critical errors. + +4. Many style guides and linters already discourage the use of bare except + clauses. + + +Specification +============= + +The syntax for the except clause will be modified to require an exception type. +The grammar will be updated to remove the possibility of adding an empty +expression in except clauses. + +This change disallows the bare ``except:`` syntax. All except clauses must +specify at least one exception type: + +.. code-block:: python + + try: + ... + except ValueError: + ... + except (TypeError, RuntimeError): + ... + except Exception: + ... # Still allowed, but catches all exceptions explicitly + +The semantics of exception handling remain unchanged, except that it will no +longer be possible to catch all exceptions without explicitly specifying +``BaseException`` or a similarly broad exception type. + + +Backwards Compatibility +======================= + +This change is not backwards compatible. Existing code that uses bare ``except:`` +clauses will need to be modified. To ease the transition: + +1. A deprecation warning will be issued for bare except clauses in Python 3.14. +2. The syntax will be fully disallowed in Python 3.17. +3. A ``from __future__ import strict_excepts`` will be provided to invalidate bare + except handlers in earlier versions of Python. + +A tool will be provided to automatically update code to replace bare ``except:`` +with ``except BaseException:``. + + +Security Implications +===================== + +This change has no security implications. + + +How to Teach This +================= + +For new Python users, exception handling should be taught with explicit +exception types from the start: + +.. code-block:: python + + try: + result = risky_operation() + except ValueError: + handle_value_error() + except TypeError: + handle_type_error() + except Exception as e: + handle_unexpected_error(e) + +For experienced users, the change can be introduced as a best practice that is +now enforced by the language. The following points should be emphasized: + +1. Always catch specific exceptions when possible. +2. Use ``except Exception:`` as a last resort for truly unexpected errors. +3. Never silence exceptions without careful consideration. + +Documentation should guide common exception hierarchies and how to choose +appropriate exception types to catch. + +Rejected ideas +============== + +* There are genuine cases where the use of bare ``except:`` handlers are correct. one + of the examples that have been raised from Mailman [8]_ involves handling transactions + in the face of any exception: + + .. code-block:: python + + @contextmanager + def transaction(): + """Context manager for ensuring the transaction is complete.""" + try: + yield + except: + config.db.abort() + raise + else: + config.db.commit() + + This code guarantees that no matter what exception occurs, any open + transaction will be aborted, while in the successful condition, the + transaction will be committed. + + We do believe that although there are cases such like this one where + bare ``except:`` handlers are correct, it would be better to actually + be explicit and use ``except BaseException:`` for the reasons indicated + in the "Motivation" section. + + +Copyright +========= + +This document is placed in the public domain or under the +CC0-1.0-Universal license, whichever is more permissive. + +.. [1] https://pylint.pycqa.org/en/latest/user_guide/messages/warning/bare-except.html +.. [2] https://www.flake8rules.com/rules/E722.html +.. [3] https://docs.astral.sh/ruff/rules/bare-except/ +.. [4] https://google.github.io/styleguide/pyguide.html#24-exceptions +.. [5] https://chromium.googlesource.com/chromiumos/platform/factory/+/HEAD/CODING_STYLE.md#Avoid-bare_except +.. [6] https://4.docs.plone.org/develop/plone-coredev/style.html#concrete-rules +.. [7] https://docs.openedx.org/en/latest/developers/references/developer_guide/style_guides/python-guidelines.html +.. [8] https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/database/transaction.py#L27 +