Guido van Rossum wrote:
> 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
Eric Nieuwland wrote:
> If I interpret the above translation correctly, then:
> try:
> BLOCK1
> except EXCEPTION1, VAR1:
> try:
> BLOCK2
> except EXCEPTION2, VAR2:
> HANDLER
>
> with exceptions occuring in BLOCK1, BLOCK2 and HANDLER would result in
> HANDLER's exception with __context__ set to BLOCK1's exception and
> BLOCK2's exception would be lost.
Guido van Rossum wrote:
> But that could easily be fixed by appending the context to the end of
> the chain, right?
That would fix this case, but i have a hard time proving to myself that
the result would include all the tracebacks in chronological order.
Can be back up and see if we can agree on a specification at a semantic
level first? I've been trying to narrow down exactly what you seem to
intuitively want -- how do you like the following:
Definition of "context": An exception-raise event X is the context
for an exception-raise event Y if and only if
1. Y occurs after X in the same thread.
2. If an 'except' clause catches X, Y occurs before exit from this
clause and is not caught before exit from this clause.
(I refer to "exception-raise events" to avoid any ambiguity about the
same exception object being raised twice. Each raise-event corresponds
to at most one catch.)
-- ?!ng
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4