[Python-Dev] Re-raise in absence of an "active" exception

[Alex Martelli]

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 
>> raised
>> 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"
...     raise
...
 >>> 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:
         try:
             raise
         except SystemExit:
             raise
         except:
             erf = sys.__stderr__
             (etc etc)
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.


Alex