Title: Misleading variable name in exception handling
Type: Stage: resolved
Components: Interpreter Core Versions: Python 3.6
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: BTaskaya, Valentin.Lorentz, vstinner
Priority: normal Keywords:

Created on 2016-04-25 19:56 by Valentin.Lorentz, last changed 2019-12-20 19:10 by vstinner. This issue is now closed.

Messages (3)
msg264198 - (view) Author: ProgVal (Valentin.Lorentz) Date: 2016-04-25 19:56
In Python/errors.c, PyErr_Restore is defined this way:

PyErr_Restore(PyObject *type, PyObject *value, PyObject *traceback)

In Python/ceval.c, in the END_FINALLY case, it is called like this:

PyErr_Restore(status, exc, tb);

I believe “exc” should be renamed to “val”.

Indeed, END_FINALLY pops values from the stack like this:

PyObject *status = POP();
// ...
else if (PyExceptionClass_Check(status)) {
     PyObject *exc = POP();
     PyObject *tb = POP();
     PyErr_Restore(status, exc, tb);

And, they are pushed like this, in fast_block_end:

msg358716 - (view) Author: Batuhan Taskaya (BTaskaya) * (Python committer) Date: 2019-12-20 16:22
I am not sure if calls like this constitutes a problem. By the way most of the things changed in Python/ceval.c including removal of END_FINALLY (issue 33387) but calls to _PyErr_Restore is still there with that same arguments.
msg358728 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-12-20 19:10
Variable names have no impact on the execution. Sometimes, it's called "exc", sometimes "val", sometimes "exc_val" :-) This issue is not a bug.
Date User Action Args
2019-12-20 19:10:58vstinnersetstatus: open -> closed
resolution: not a bug
messages: + msg358728

stage: resolved
2019-12-20 16:22:44BTaskayasetnosy: + vstinner, BTaskaya
messages: + msg358716
2016-04-25 19:56:07Valentin.Lorentzcreate