This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author poke
Recipients draghuram, eric.araujo, ethan.furman, mrabarnett, ncoghlan, pitrou, poke, rhettinger, steven.daprano
Date 2010-12-30.13:30:01
SpamBayes Score 1.66533e-16
Marked as misclassified No
Message-id <1293715804.49.0.624962778611.issue6210@psf.upfronthosting.co.za>
In-reply-to
Content
Nick Coghlan (ncoghlan) at 2010-12-29 08:46 (UTC):
> No, the context must always be included unless explicitly suppressed.

Then there should be some actually working way to suppress it, right?

I think the standard behaviour that automatically sets the `__context__` of an exception is fine, especially when thinking about exceptions that get raised inside `except` blocks and are not custom made. However there should be some way to suppress the context in some way.

Personally, I would prefer if `raise .. from ..` would set the exception's cause, but would *not* automatically print that cause. But then again, it would be a problem to get the cause afterwards when the program terminated because of that exception. So obviously, in such situations, both the cause and the context of a raised exception cannot be used (because both prints out the full trackback).

So we obviously need some new mechanism or syntax to ignore the previous exception. As it seems that the cause has a higher precedence than the context (which is fine as the cause is changeable), using `None` as the cause of an exception would be the best solution in my opinion:

    try:
        x / y
    except ZeroDivisionError as e:
        raise Exception( 'Invalid value for y' ) from None

While it might be difficult as the cause is `None` before and gets set to `None` afterwards, Python is totally able to detect that the value was explicitely set to `None`. Either the raise statement should set some internal flag, or the setter for `__cause__` should just check when it is first written to.

If that would be too complicated (although it would be possible and very logically to do it like that), maybe a different syntax would work:

    try:
        x / y
    except ZeroDivisionError as e:
        raise Exception( 'Invalid value for y' ) instead

Something like that.
History
Date User Action Args
2010-12-30 13:30:04pokesetrecipients: + poke, rhettinger, ncoghlan, pitrou, draghuram, eric.araujo, mrabarnett, steven.daprano, ethan.furman
2010-12-30 13:30:04pokesetmessageid: <1293715804.49.0.624962778611.issue6210@psf.upfronthosting.co.za>
2010-12-30 13:30:01pokelinkissue6210 messages
2010-12-30 13:30:01pokecreate