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 steven.daprano
Recipients aronacher, catalin.iacob, draghuram, eric.araujo, ethan.furman, ezio.melotti, georg.brandl, mrabarnett, ncoghlan, pitrou, poke, rhettinger, steven.daprano
Date 2012-01-29.23:30:49
SpamBayes Score 4.50084e-13
Marked as misclassified No
Message-id <>
In-reply-to <>
Patrick Westerhoff wrote:
> Patrick Westerhoff <> added the comment:
> I have to agree with Georg on that. I think it would make more sense to
> introduce some internal flag/variable that keeps track of if the cause was
> explicitely set. So if cause was set (i.e. `from X` syntax is used), then
> always display it in favor of the context – except that a None-cause causes
> nothing to display.
> Regardless of that I’m actually not sure if just changing the way the cause
> is displayed is a correct way to handle the context. If I explicitely raise
> an exception in an except-handler, I usually don’t expect that new
> exception to get the previous exception attached to.

I'm inclined to agree. I'm not convinced that "raise MyError from None" should 
leave any trace of the old exception at all.

Suppose you have a couple of functions like this:

def spam(x):    # LBYL
     if hasattr(x, "__len__"):
         y = len(x)+1
         raise MyError("x has no length")

def ham(x):    # EAFP
         y = len(x)+1
     except TypeError:
         raise MyError("x has no length") from None

It is entirely an irrelevant implementation detail whether you happen to write 
spam or ham. The exception that the caller gets should, in my opinion, be the 
same. I can't see any benefit to exposing the TypeError, even if the caller 
has to overtly go looking for it in order to see it.

But having said that, if others have a specific scenario in mind where they 
would need to distinguish between spam and ham, I'm happy for the context to 
be set. But I am curious to learn what the scenario is. Is it just a matter of 
"just in case"?
Date User Action Args
2012-01-29 23:30:50steven.dapranosetrecipients: + steven.daprano, georg.brandl, rhettinger, ncoghlan, pitrou, draghuram, aronacher, ezio.melotti, eric.araujo, mrabarnett, poke, ethan.furman, catalin.iacob
2012-01-29 23:30:50steven.dapranolinkissue6210 messages
2012-01-29 23:30:49steven.dapranocreate