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 ncoghlan
Recipients adaptivelogic, eric.snow, gvanrossum, martius, ncoghlan, pitrou, rbcollins, rhettinger, vstinner, yselivanov
Date 2015-01-27.13:23:03
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1422364984.09.0.397768580574.issue17911@psf.upfronthosting.co.za>
In-reply-to
Content
Most of the time when I'm working heavily with exceptions it's something related to contextlib, so I'm likely getting my exception details from either sys.exc_info() or the arguments to __exit__. That means I start out with an exception triple, and the only time I need to look at type(exc) or exc.__traceback__ is when I'm following exception chains.

However, Antoine's right that if you got your exception from an *except clause* rather than one of the more indirect APIs, then you're just going to have the exception, rather than an exception triple.

So I think that's where the argument for accepting "exception-or-triple" comes from: handling an exception directly is for use with except clauses, while handling triples is convenient for use with sys.exc_info(), __exit__ methods and for general backwards compatibility.
History
Date User Action Args
2015-01-27 13:23:04ncoghlansetrecipients: + ncoghlan, gvanrossum, rhettinger, pitrou, vstinner, rbcollins, eric.snow, yselivanov, adaptivelogic, martius
2015-01-27 13:23:04ncoghlansetmessageid: <1422364984.09.0.397768580574.issue17911@psf.upfronthosting.co.za>
2015-01-27 13:23:04ncoghlanlinkissue17911 messages
2015-01-27 13:23:03ncoghlancreate