[issue26845] Misleading variable name in exception handling

[STINNER Victor]

STINNER Victor  added the comment:

Variable names have no impact on the execution. Sometimes, it's called "exc", 
sometimes "val", sometimes "exc_val" :-) This issue is not a bug.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26845] Misleading variable name in exception handling

[Batuhan]

Batuhan  added the comment:

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.

--
nosy: +BTaskaya, vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26845] Misleading variable name in exception handling

[ProgVal]

New submission from ProgVal:

In Python/errors.c, PyErr_Restore is defined this way:

void
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:

PUSH(tb);
PUSH(val);
PUSH(exc);

--
components: Interpreter Core
messages: 264198
nosy: Valentin.Lorentz
priority: normal
severity: normal
status: open
title: Misleading variable name in exception handling
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com