> When working on the sets module, a bug was found > where trapping an exception (a TypeError for a mutable > argument passed to a dictionary) resulted in masking > other errors that should have been passed through > (potential TypeErrors in the called iterator for example). > > Now, Walter is working on a bug for map(), zip(), and > reduce() where errors in the getiter() call are being > trapped, reported as TypeError (for non-iterability), > but potentially masking other real errors in > a __iter__ routine. The current proposed solution is > to remove the PyErr_Format call so that the underlying > error message gets propagated up its original form. > The downside of that approach is that it loses information > about which argument caused the error. > > So, here's the bright idea. Add a function, > PyErr_FormatAppend, that leaves the original message > intact but allows additional information to be added > (like the name of the called function, identification > of which argument triggered the error, a clue as > to how many iterations had passed, or anything else > that makes the traceback more informative). > > Python code has a number of cases where a higher > level routine traps an exception and reraises it with > new information and losing the lower level error > detail in the process. Was a conclusion reached in this thread? It seems a good idea. --Guido van Rossum (home page: http://www.python.org/~guido/)
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