[Python-3000] The future of exceptions

[Jack Diederich]

On Sat, Sep 02, 2006 at 06:36:37PM +0200, Georg Brandl wrote:
> While looking at the changes necessary to implement the exception
> related syntax changes (except ... as ..., raise without type),
> I came across some more substantial things that I think must be discussed.
> 
> * How should exceptions be represented in C code? Should there still
>   be a (type, value, traceback) triple?
> 
> * Could the traceback be made an attribute of the exception?
> 
> * What about exception chaining?
> 
The last time this came up everyone's eyes glazed over and the conversation
stopped.  That doesn't mean it isn't worth talking about it just means that
exceptions are hard and potentially make GC miserable.

> Something like this comes to mind::
> 
>     try:
>         whatever
>     except ValueError as err:
>         raise CustomException("Something went wrong", prev=err)
> 
> With tracebacks becoming part of the exception, that could be::
> 
>     raise CustomException(*args, prev=err, tb=traceback)
> 
> (`prev` and `tb` would be keyword-only arguments)
> 
> With that, all exception info would be contained in one object,
> so sys.exc_info() could be renamed to sys.last_exc().
> 

The current system is awkward if you want to do fancy things with
exceptions and tracebacks.  I've never had to do fancy things with
exceptions and tracebacks so I'm OK with it.  "raise" as a bare word
covers all the cases where I need to catch, inspect, and potentially
reraise the original.  In the above example you are just annotating
and reraising an error so a KISS suggestion might go

try:
  whatever
except ValueError as err:
  err.also_squawk += 'Kilroy was here'
  raise

Where 'also_squawk' was renamed to something more intuitive and much
more international.

-Jack