[Python-Dev] PEP for allowing 'raise NewException from None'

Terry Reedy tjreedy at udel.edu
Fri Jan 27 23:40:16 CET 2012

On 1/27/2012 2:54 PM, Guido van Rossum wrote:
> On Fri, Jan 27, 2012 at 9:08 AM, Ethan Furman<ethan at stoneleaf.us>  wrote:
>> Guido van Rossum wrote:
>>> Did you consider to just change the
>>> words so users can ignore it more easily?
>> Yes, that has also been discussed.
>> Speaking for myself, it would be only slightly better.
>> Speaking for everyone that wants context suppression (using Steven
>> D'Aprano's words):  chained exceptions expose details to the caller that are
>> irrelevant implementation details.

Especially if the users are non-programmer app users.

>> It seems to me that generating the amount of information needed to track
>> down errors is a balancing act between too much and too little; forcing the
>> print of previous context when switching from exception A to exception B
>> feels like too much:  at the very least it's extra noise; at the worst it
>> can be confusing to the actual problem.  When the library (or custom class)
>> author is catching A, saying "Yes, expected, now let's raise B instead", A
>> is no longer necessary.

I find double tracebacks to be 'jarring'. If there is a double bug, one 
in both the try and except blocks, it *should* stand out. If there is 
just one bug and the developer merely wants to rename it and change the 
message, it should not.
>> Also, the programmer is free to *not* use 'from None', leaving the complete
>> traceback in place.
> Ok, got it. The developer has to explicitly say "raise<something>
> from None" and that indicates they have really thought about the issue
> of suppressing too much information and they are okay with it. I dig
> that.

Now that I have been reminded that 'from x' was already added to raise 
statements, I am fine with reusing that. I still think it 'sticks out' 
more than the 'as' version, but when reading code, having (rare) info 
suppression stick out is not so bad.

The PEP does not address the issue of whether the new variation of raise 
is valid outside of an except block. My memory is that it was not to be 
and I think it should not be. One advantage of the 'as' form is that it 
is clear that raising the default as something else is invalid if there 
is no default.

Terry Jan Reedy

More information about the Python-Dev mailing list