RetroSearch Browse

Sat Jan 21 07:07:00 CET 2012 · https://mail.python.org/pipermail/python-dev/2012-January/115777.html

On 1/20/2012 7:40 PM, Steven D'Aprano wrote:
> Benjamin Peterson wrote:
>> 2012/1/20 Terry Reedy <tjreedy at udel.edu>:
>>> Since 'raise' means 're-raise the current error', 'raise as OtherError'
>>> means (clearly to me, anyway) 're-raise the current error as
>>> OtherError'.
>>
>> That doesn't make any sense. You're changing the exception completely
>> not reraising it.
>
> I expect Terry is referring to the coder's intention, not the actual
> nuts and bolts of how it is implemented.

Yes, same error situation, translated, typically from developer language 
to app language.

> def spam():
> try:
> something()
> except HamError:
> raise SpamError
>
> is implemented by catching a HamError and raising a completely different
> SpamError, but the intention is to "replace the HamError which actually
> occurred with a more appropriate SpamError".
>
> At least that is *my* intention when I write code like the above, and it
> appears to be the usual intention in code I've seen that uses that
> idiom. Typically SpamError is part of the function's API while HamError
> is not.

-- 
Terry Jan Reedy

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2012-January/115777.html below:

[Python-Dev] exception chaining