classification
Title: Lexical exception handlers
Type: behavior Stage:
Components: Interpreter Core Versions: Python 3.0
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: benjamin.peterson Nosy List: Rhamphoryncus, benjamin.peterson, pitrou
Priority: normal Keywords: patch

Created on 2008-06-01 20:03 by pitrou, last changed 2008-06-11 16:00 by benjamin.peterson. This issue is now closed.

Files
File name Uploaded Description Edit
exc_stacking.patch pitrou, 2008-06-01 20:03
finally.patch pitrou, 2008-06-07 20:58
Messages (10)
msg67598 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2008-06-01 20:03
This patch implements the proposal outlined on the py3k mailing-list
here: http://mail.python.org/pipermail/python-3000/2008-May/013740.html

It solves both #2507 and #2833, and even improves re-raising semantics
in several cases (see the test cases which were added to test_raise.py).

Anothing thing worth noting is that f_exc_* fields are not accessible
from Python code anymore, because their semantics is an implementation
detail and shouldn't be relied upon.
msg67782 - (view) Author: Adam Olsen (Rhamphoryncus) Date: 2008-06-06 20:09
PEP 3134's implicit exception chaining (if accepted) would require your
semantic, and your semantic is simpler anyway (even if the
implementation is non-trivial), so consider my objections to be dropped.

PEP 3134 also proposes implicit chaining during a finally block, which
raises questions for this case:

try:
    ...
finally:
    print(sys.exc_info())
    raise

If sys.exc_info() were removed (with no direct replacement) we'd have
that behaviour answered.  raise could be answered by making it a syntax
error, but keep in mind this may be nested in another except block:

try:
    ...
except:
    try:
        ...
    finally:
        raise

I'd prefer a syntax error in this case as well, to avoid any ambiguity
and to keep the implementation simple.
msg67789 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2008-06-06 21:54
With or without my patch, bare "raise" inside a "finally" statement
raises a "RuntimeError: no active exception to re-raise". (except, of
course, when the try/finally is itself enclosed in an except block)
That's because a finally block is not considered an exception handler. I
don't think there's any reason to change this.

I'm not for adding syntax errors. After all the bare "raise" statement
just does the moral equivalent of re-raising sys.exc_info() verbatim. In
those situations where sys.exc_info() would return a non-empty result,
why shouldn't "raise" be accepted as well?
msg67790 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2008-06-06 22:30
(an unexpected side effect of my patch is that the interpreter has
become 5-10% faster under Linux, witnessed with pystone and pybench. I
don't know the explanation)
msg67795 - (view) Author: Adam Olsen (Rhamphoryncus) Date: 2008-06-07 02:25
PEP 3134 gives reason to change it.  __context__ should be set from
whatever exception is "active" from the try/finally, thus it should be
the inner block, not the outer except block.

This flipping of behaviour, and the general ambiguity, is why I suggest
a syntax error.  "In the face of ambiguity, refuse the temptation to guess."

PEP 3134 has not been officially accepted, but many parts have be added
anyway.  Your cleanups pave the way for the last of it.  I suggest
asking on python-3000 for a pronouncement on the PEP.
msg67800 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2008-06-07 05:33
Ok, it makes sense to have the same behaviour for except and finally
blocks then. As for the syntax error, I'm still not convinced. The point
of Py3k is to change semantics: people should expect some incompatible
changes. Also the previous behaviour was rather under-specified, so it
could be considered a bug. And it seems to me syntax errors should be
used to guard against potential syntax mistakes, not semantic subtleties.
msg67801 - (view) Author: Adam Olsen (Rhamphoryncus) Date: 2008-06-07 06:37
I agree, the argument for a syntax error is weak.  It's more instinct
than anything else.  I don't think I'd be able to convince you unless
Guido had the same instinct I do. ;)
msg67816 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2008-06-07 20:58
Here is a newer patch that also adapts the behaviour of finally blocks
as suggested by Adam Olsen. Note that I had to change some things in the
way 'with' statements are compiled and executed.
msg67938 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-06-11 03:12
Guido has given the go ahead on this. I will apply in about 8 hours
(after some sleep).
msg67989 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-06-11 16:00
Commited in r64121.
History
Date User Action Args
2008-06-11 16:00:24benjamin.petersonsetstatus: open -> closed
messages: + msg67989
2008-06-11 03:12:19benjamin.petersonsetassignee: benjamin.peterson
resolution: accepted
messages: + msg67938
2008-06-07 20:58:31pitrousetfiles: + finally.patch
messages: + msg67816
2008-06-07 06:37:39Rhamphoryncussetmessages: + msg67801
2008-06-07 05:33:46pitrousetmessages: + msg67800
2008-06-07 02:25:54Rhamphoryncussetmessages: + msg67795
2008-06-06 22:30:40pitrousetmessages: + msg67790
2008-06-06 21:54:08pitrousetmessages: + msg67789
2008-06-06 20:10:02Rhamphoryncussetmessages: + msg67782
2008-06-02 07:32:08Rhamphoryncussetnosy: + Rhamphoryncus
2008-06-01 21:33:40benjamin.petersonsetnosy: + benjamin.peterson
2008-06-01 21:33:14benjamin.petersonlinkissue2833 superseder
2008-06-01 21:33:06benjamin.petersonlinkissue2507 superseder
2008-06-01 20:03:45pitroucreate