[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