[Raymond] > > 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. [GvR] > Was a conclusion reached in this thread? It seems a good idea. We ended-up with two ways to go: 1. The most lightweight, least invasive approach was one the one first proposed. It allows extra information to be tacked onto the error message string. All other mechanisms work the same way. 2. The more involved approach is keep generate an exception as keep the original one as an attribute, "the root cause". This allows more information to be retained but raises a number of issues about how to display the result, whether the original exception is catchable, whether we want to intercept all exceptions, etc. The first approach is the "simplest thing that could possibly work". It is easy to implement, understand, and use. The second one would need to be teased out a lot more than it has been. Raymond Hettinger
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