On 05/20/2013 06:47 AM, Nick Coghlan wrote: > On 20 May 2013 23:38, Ethan Furman wrote: >> >> As a quick reminder, PEP 409 allows this: >> >> try: >> ... >> except AnError: >> raise SomeOtherError from None >> >> so that if the exception is not caught, we get the traditional single exception traceback, instead of the new: >> >> During handling of the above exception, another exception occurred >> >> >> My question: >> >> How do we go about putting this in the stdlib? Is this one of the occasions where we don't do it unless we're modifying a module already for some other reason? >> >> For that matter, should we? >> >> Pros: Makes tracebacks much less confusing, especially coming from a library >> >> Cons: Could hide bugs unrelated to what is being caught and transformed > > Be pretty conservative with this one - we should only use it when we're confident we know the original exception is > almost certain to be irrelevant noise. > > Ensuring the traceback module makes it easy to display both would also be a good preliminary step. As a case in point, base64.py is currently getting a bug fix, and also contains this code: def b32decode(s, casefold=False, map01=None): . . . for i in range(0, len(s), 8): quanta = s[i: i + 8] acc = 0 try: for c in quanta: acc = (acc << 5) + b32rev[c] except KeyError: raise binascii.Error('Non-base32 digit found') . . . else: raise binascii.Error('Incorrect padding') Does the KeyError qualify as irrelevant noise? If we're not going to suppress the originating error I think we should at least change the double trace back message as it implies two failures, instead of just one. -- ~Ethan~
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4