Semantics of propagated exceptions

[Marc 'BlackJack' Rintsch]

In <pan.2006.07.21.09.57.12.847175 at ID-174572.user.uni-berlin.de>, Thomas
Lotze wrote:

> I wonder how to solve the following problem the most pythonic way:
> 
> Suppose you have a function f which, as part of its protocol, raises some
> standard exception E under certain, well-defined circumstances. Suppose
> further that f calls other functions which may also raise E. How to best
> distinguish whether an exception E raised by f has the meaning defined by
> the protocol or just comes from details of the implementation?
> 
> […]
>
> Several solutions come to mind, neither of which I'm satisfied with:
> 
> - f might catch E exceptions from the implementation and raise some other
> error in their stead, maybe with an appropriate message or treating the
> traceback in some helpful way. This destroys the original exception.

This is the way to go I think.  After all it's not an ordinary `E` but one
that has a special, well defined meaning if raised by `f` itself according
to your protocol.

Put the original exception as an attribute to the new one and/or subclass
the new exception type from `E`.  This way calling code can choose to to
handle both types as `E` if the distinction is not important.

Ciao,
	Marc 'BlackJack' Rintsch