Guido van Rossum wrote:
There's a lot of C code out there that catches e.g. AttributeError and replaces it with a more specific error (e.g. BifurcationError("can't bifurcate the sploorg") replacing AttributeError("__bifurcate__"). I think this would cause end user confusion.
But that is a different case. As I understand it, chaining would only occur if a second exception was raised *before* the current exception was caught -- e.g. if there's a bug in a piece of code in a finally block that's being executed while unwinding to find an exception handler.
Interesting.. I had never even thought of this case. I thought chaining was specifically when catching an exception and raising another in its place.
To the people who came up with the idea, which is it?
I only though about the the case, where one exception is has already been raised is replaced with another exception. Exceptions in a finally clause is an interesting new scenario.
(I can see an argument for both cases; maybe they should be supported using different system attributes on the exception object?)
Sounds reasonable. If we don't want the exception replacement case to chain the exceptions automatically, we'd need this argument/attribute in all exception constructors. For the finally cause the attribute should be set by the exception machinery. Bye, Walter Dörwald