[Python-3000] The future of exceptions

Brett Cannon brett at python.org
Sat Sep 2 22:44:00 CEST 2006


On 9/2/06, Georg Brandl <g.brandl at gmx.net> 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.


You have read Ping's PEP 344, right?

* 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?


The problem with this is that it keeps the frame alive.  This is why this
and exception chaining were considered a design issue in Ping's PEP since
that is a lot of stuff to keep alive.

* What about exception chaining?
>
> 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().


Right, which is why the original suggestion came up in the first place.  It
would be nice to compartmentalize exceptions entirely, but the worry of
keeping a ont of memory alive for it needs to be addressed, especially if
exceptions are to be kept lightweight and usable for things other than
flagging errors.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060902/9caf2f96/attachment.html 


More information about the Python-3000 mailing list