On Tue, 28 Jan 2003 19:22:34 -0500 "Raymond Hettinger" email@example.com 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.