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
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