On Tue, 28 Jan 2003 19:22:34 -0500 "Raymond Hettinger" <raymond.hettinger@verizon.net> wrote: > 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). > There is a difficulty with c functions that implement "overloaded" behaviour: if the first PyArg_ParseTuple fails, clear the error and then if the second PyArg_ParseTyple fails (then if ...), that's the error that is raised. I came across this problem in the pygtk wrapper. James Henstridge suggested that the (final) error should be cleared and then raise an error manually (PyErr_FromString), OK, but this duplicates error information. What i'd really like to see is something similar to Raymond's suggestion, allowing a way to raise a disjunction of errors; we don't know which one is the real error, so raise them all, perhaps inside another "OneOf" error. Simon Burton.
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