[Python-Dev] Re-raise in absence of an "active" exception
aleaxit at yahoo.com
Fri Jun 25 05:20:33 EDT 2004
On 2004 Jun 24, at 17:15, Jeremy Hylton wrote:
> On Mon, 2004-06-21 at 01:22, "Martin v. Löwis" wrote:
>> "If no exception is active in the current scope, an exception is
>> indicating this error."
>> "This" error probably being "no active exception", not "exception must
>> not be NoneType".
> We can determine statically whether an exception would active in the
> current scope, right? If the raise does not occur within an except
> handler, then there is no active exception in the current scope. I
> think it should be a SyntaxError.
Isn't the "raise" allowed to occur in a function that may be _called
from_ an except handler? E.g.:
>>> def foo():
... print "do something here"
>>> try: 1/0
... except Exception: foo()
as one might obtain from refactoring otherwise duplicated "clean up a
few things after an exception, then propagate the exception" code into
a function foo. Of course, this could easily be coded otherwise (just
a bit more verbosely: keep the raise out of foo, use "foo(); raise"
wherever foo is now called), but before making a SyntaxError out of a
construct that's long been quite correct and may well be present in
good working code one would surely need at least one transition release
where the construct produces a warning, right?
Indeed. I looked for examples in the Python standard library and it
wasn't hard to find some (there may be others, I only did a quick rough
search) -- compiler/pycodegen.py method visitSlice of class
CodeGenerator has a bare raise as the very last line of code (NOT
statically inside an except handler); idlelib/rpc.py has a really
interesting construct in method handle_error of class RPCServer:
erf = sys.__stderr__
also found elsewhere in idlelib, and another simpler bare raise is also
in handle_error in class MyMixinServer in test_socketserver.py (indeed
such handle_error methods might seem good candidates for cases of "bare
raise not statically within an except handler"). It appears to me that
finding examples of use of a construct inside such "hallowed" code as
found in the standard library further militates in favour of having to
be very cautious before making that construct into a SyntaxError.
More information about the Python-Dev