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

Steven D'Aprano steve at pearwood.info
Sat Jan 28 01:50:16 CET 2012

Terry Reedy wrote:
> 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.

Or beginner programmers, e.g. on the python-list and tutor mailing lists. It 
is hard enough to get beginners to post the entire traceback without making 
them bigger. The typical newbie posts just the error message, sometimes not 
even the exception type. What they will make of chained exceptions, I hate to 

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

Agreed with all of this.

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

I think that raise ... from None should be illegal outside an except block. My 
reasoning is:

1) It ensures that raise from None only occurs when the developer can see
    the old exception right there, and not "just in case".

2) I can't think of any use-cases for raise from None outside of an
    except block.

3) When in doubt, start with something more restrictive, because it is
    easier to loosen the restriction later if it turns out to be too much,
    than to change our mind and add the restriction afterwards.


More information about the Python-Dev mailing list