Add `finally as e`

[iritkatriel]

@blhsing

The first item makes sense to me for logging the traceback of a non-critical error before allowing the execution to move on:

try:
    raise NonCriticalError
except:
    traceback.print_exc()

# continue execution

The reason that PEP 8 and linters advise against using except: is that it catches all exceptions, and any code can raise exceptions that you should treat as critical (in the sense that the program should not ignore them). The usual examples are KeyboardInterrupt and MemoryError, but there are other cases. Simply logging that fact that someone requested to exit the program with a ctrl-C and moving on doesn’t make sense.

@csm10495

We separate out the different exception handlers but then sort of always handle the finally as exception as a generic exception with all matches going into it.

Strictly speaking, it’s the exception that is in-flight when the finally block executes. This is any exception that was not caught, caught and reraised, or a new exception raised from an except clause. If finally as e is confusing, maybe finally e (as I originally proposed) works better.

@csm10495

It makes me wonder: How common is this pattern to begin with? I can’t think of a recent case where I needed the exception inside the finally block since I used it in the except block.

This is proposed as an alternative to

except:
   ...
   raise

If you look for this pattern (say in the stdlib) you will find it used quite a bit.