[Python-Dev] Chained Exceptions

[Ka-Ping Yee]

On Thu, 12 May 2005, Guido van Rossum wrote:
> Define "raise". Does that involve a raise statement?

Not necessarily; it could be a raise statement or an inadvertently
triggered exception, such as in the example code i posted.

> What about 1/0?

That counts.

> What if you call a method that executes 1/0?

That counts too.

> What if that method catches that exception?

Did you mean something like this?

    def handle():
        try:
            open('spamspamspam')
        except:
            catchit()
            # point A
            ...

    def catchit():
        try:
            1/0
        except:
            pass

Then there's no exception to propagate, so it doesn't matter.
Once we're get to point A, the division by zero is long forgotten.

> What about the StopIteration conceptually
> raised by next() called by the for-loop implementation?

It's "caught" by the for-loop, so to speak, so it never gets out.
Conceptually, the for-loop expands to:

    while 1:
        try:
            item = it.next()
        except StopIteration:
            break
        # body of loop goes here

The 'break' can't possibly cause an exception, so the StopIteration
exception isn't retained.

> I believe there are (at least) two use cases:
>
> (1) I catch some low-level exception (e.g. socket.error) and turn it
> into a high-level exception (e.g. an HTTPRequestFailed exception).
>
> (2) I write some exception handling code and somehow a bug in the
> handler (or an uncooperative environment, e.g. a full disk) causes the
> exception handling code to trip over an exception.
>
> I'm fairly certain (but not 100%) that Ping meant to include both use cases.

Yes, though i did not expect to provide any mechanism for distinguishing
the two cases.  Do you think such a mechanism would be necessary?


-- ?!ng