A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://python.github.io/peps/pep-0490/ below:

PEP 490 – Chain exceptions at C level

PEP 490 – Chain exceptions at C level
Author:
Victor Stinner <vstinner at python.org>
Status:
Rejected
Type:
Standards Track
Created:
25-Mar-2015
Python-Version:
3.6
Table of Contents Abstract

Chain exceptions at C level, as already done at Python level.

Rationale

Python 3 introduced a new killer feature: exceptions are chained by default, PEP 3134.

Example:

try:
    raise TypeError("err1")
except TypeError:
    raise ValueError("err2")

Output:

Traceback (most recent call last):
  File "test.py", line 2, in <module>
    raise TypeError("err1")
TypeError: err1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "test.py", line 4, in <module>
    raise ValueError("err2")
ValueError: err2

Exceptions are chained by default in Python code, but not in extensions written in C.

A new private _PyErr_ChainExceptions() function was introduced in Python 3.4.3 and 3.5 to chain exceptions. Currently, it must be called explicitly to chain exceptions and its usage is not trivial.

Example of _PyErr_ChainExceptions() usage from the zipimport module to chain the previous OSError to a new ZipImportError exception:

PyObject *exc, *val, *tb;
PyErr_Fetch(&exc, &val, &tb);
PyErr_Format(ZipImportError, "can't open Zip file: %R", archive);
_PyErr_ChainExceptions(exc, val, tb);

This PEP proposes to also chain exceptions automatically at C level to stay consistent and give more information on failures to help debugging. The previous example becomes simply:

PyErr_Format(ZipImportError, "can't open Zip file: %R", archive);
Proposal Modify PyErr_*() functions to chain exceptions

Modify C functions raising exceptions of the Python C API to automatically chain exceptions: modify PyErr_SetString(), PyErr_Format(), PyErr_SetNone(), etc.

Modify functions to not chain exceptions

Keeping the previous exception is not always interesting when the new exception contains information of the previous exception or even more information, especially when the two exceptions have the same type.

Example of an useless exception chain with int(str):

TypeError: a bytes-like object is required, not 'type'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: int() argument must be a string, a bytes-like object or a number, not 'type'

The new TypeError exception contains more information than the previous exception. The previous exception should be hidden.

The PyErr_Clear() function can be called to clear the current exception before raising a new exception, to not chain the current exception with a new exception.

Modify functions to chain exceptions

Some functions save and then restore the current exception. If a new exception is raised, the exception is currently displayed into sys.stderr or ignored depending on the function. Some of these functions should be modified to chain exceptions instead.

Examples of function ignoring the new exception(s):

Examples of function displaying the new exception to sys.stderr:

Backward compatibility

A side effect of chaining exceptions is that exceptions store traceback objects which store frame objects which store local variables. Local variables are kept alive by exceptions. A common issue is a reference cycle between local variables and exceptions: an exception is stored in a local variable and the frame indirectly stored in the exception. The cycle only impacts applications storing exceptions.

The reference cycle can now be fixed with the new traceback.TracebackException object introduced in Python 3.5. It stores information required to format a full textual traceback without storing local variables.

The asyncio is impacted by the reference cycle issue. This module is also maintained outside Python standard library to release a version for Python 3.3. traceback.TracebackException will maybe be backported in a private asyncio module to fix reference cycle issues.

Alternatives No change

A new private _PyErr_ChainExceptions() function is enough to chain manually exceptions.

Exceptions will only be chained explicitly where it makes sense.

New helpers to chain exceptions

Functions like PyErr_SetString() don’t chain automatically exceptions. To make the usage of _PyErr_ChainExceptions() easier, new private functions are added:

Helper functions to raise specific exceptions like _PyErr_SetKeyError(key) or PyErr_SetImportError(message, name, path) don’t chain exceptions. The generic _PyErr_ChainExceptions(exc_type, exc_value, exc_tb) should be used to chain exceptions with these helper functions.

Appendix PEPs Python C API

The header file Include/pyerror.h declares functions related to exceptions.

Functions raising exceptions:

Helpers to raise specific exceptions:

Manage the current exception:

Others function to handle exceptions:

Python Issues

Chain exceptions:

Changes preventing to loose exceptions:

Rejection

The PEP was rejected on 2017-09-12 by Victor Stinner. It was decided in the python-dev discussion to not chain C exceptions by default, but instead chain them explicitly only where it makes sense.

Copyright

This document has been placed in the public domain.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4