Idea for avoiding exception masking

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. Raymond Hettinger

"KY" == Ka-Ping Yee <ping@zesty.ca> writes:
>> 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. KY> How about just holding on to the original exception and KY> storing it as an attribute (e.g. "cause") on the new KY> exception? +1. You may actually have a chain of exceptions so being able to follow these using a well-known attribute is a good thing. -Barry

Barry A. Warsaw wrote:
It would be good to not only hold on to the exception, but to be able to tell where the original exception originated, i.e. to be able get a traceback for both exceptions. See http://mail.python.org/pipermail/python-dev/2002-March/021846.html for an old thread about this topic. So what would exception chaining mean for the C API? PyErr_SetString(PyExc_TypeError, "wrong type"); PyErr_SetString(PyExc_TypeError, "can't iterate"); The second call would normalize the first exception and attach it to the second as the cause attribute? But then the second exception would have to be normalized too. Bye, Walter Dörwald

To maintain delayed normalisation, there would have to be a fourth global variable holding the current "cause" (a normalised exception or None). Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+

On Wed, Jan 29, 2003, Barry A. Warsaw wrote:
This sounds good to me. Not being the person most familiar with frames and exceptions, though, I'm wondering what effects (if any) this will have on unexpected retention of local names. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "Argue for your limitations, and sure enough they're yours." --Richard Bach

On Tue, 28 Jan 2003 19:22:34 -0500 "Raymond Hettinger" <raymond.hettinger@verizon.net> wrote:
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.

Was a conclusion reached in this thread? It seems a good idea. --Guido van Rossum (home page: http://www.python.org/~guido/)

"KY" == Ka-Ping Yee <ping@zesty.ca> writes:
>> 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. KY> How about just holding on to the original exception and KY> storing it as an attribute (e.g. "cause") on the new KY> exception? +1. You may actually have a chain of exceptions so being able to follow these using a well-known attribute is a good thing. -Barry

Barry A. Warsaw wrote:
It would be good to not only hold on to the exception, but to be able to tell where the original exception originated, i.e. to be able get a traceback for both exceptions. See http://mail.python.org/pipermail/python-dev/2002-March/021846.html for an old thread about this topic. So what would exception chaining mean for the C API? PyErr_SetString(PyExc_TypeError, "wrong type"); PyErr_SetString(PyExc_TypeError, "can't iterate"); The second call would normalize the first exception and attach it to the second as the cause attribute? But then the second exception would have to be normalized too. Bye, Walter Dörwald

To maintain delayed normalisation, there would have to be a fourth global variable holding the current "cause" (a normalised exception or None). Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+

On Wed, Jan 29, 2003, Barry A. Warsaw wrote:
This sounds good to me. Not being the person most familiar with frames and exceptions, though, I'm wondering what effects (if any) this will have on unexpected retention of local names. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "Argue for your limitations, and sure enough they're yours." --Richard Bach

On Tue, 28 Jan 2003 19:22:34 -0500 "Raymond Hettinger" <raymond.hettinger@verizon.net> wrote:
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.

Was a conclusion reached in this thread? It seems a good idea. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (10)
-
Aahz
-
barry@python.org
-
Brett Cannon
-
Greg Ewing
-
Guido van Rossum
-
Ka-Ping Yee
-
Raymond Hettinger
-
Raymond Hettinger
-
Simon Burton
-
Walter Dörwald