[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-dev
Subject:    Re: [Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks
From:       Guido van Rossum <gvanrossum () gmail ! com>
Date:       2005-05-17 14:41:42
Message-ID: ca471dc20505170741204b8dfe () mail ! gmail ! com
[Download RAW message or body]

I figured out the semantics that I'd like to see intuitively for
setting the context. I'm not saying this is all that reasonable, but
I'd like throw it out anyway to see what responses it gets.

Consider

    try:
        BLOCK
    except EXCEPTION, VAR:
        HANDLER

I'd like to see this translated into

    try:
        BLOCK
    except EXCEPTION, VAR:
        __context = VAR
        try:
            HANDLER
        except Exception, __error:
            __error.__context__ = __context
            raise

i.e. the context is set only upon *leaving* the handler. (The
translation for finally is hairier but you get the idea at this
point.)

My intuition prefers this over Ping's solution because HANDLER could
easily invoke code that (after many stack levels deep) raises and
catches many exceptions, and I'd hate to see all those be bothered by
the context (far down on the stack) that is irrelevant.

BTW, please study how the traceback is built up. I believe that if we
store the traceback in the exception instance, we have to update the
__traceback__ attribute each time we pop a stack level. IIRC that's
how the traceback chain is built up. (The alternative, building the
whole chain  when the exception is raised, would be too expensive for
exceptions raised *and* caught somewhere deep.)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-dev%40progressive-comp.com
[prev in list] [next in list] [prev in thread] [next in thread]