Movatterモバイル変換

[Python-Dev] Idea for avoiding exception masking

• Previous message:[Python-Dev] the new 2.3a1 settimeout() with httplib and SSL
• Next message:[Python-Dev] Idea for avoiding exception masking
• Messages sorted by:[ date ][ thread ][ subject ][ author ]

When working on the sets module, a bug was foundwhere trapping an exception (a TypeError for a mutableargument passed to a dictionary) resulted in maskingother 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(), andreduce() where errors in the getiter() call are beingtrapped, reported as TypeError (for non-iterability),but potentially masking other real errors in a __iter__ routine.  The current proposed solution isto remove the PyErr_Format call so that the underlyingerror message gets propagated up its original form.The downside of that approach is that it loses informationabout which argument caused the error.So, here's the bright idea.  Add a function, PyErr_FormatAppend, that leaves the original messageintact but allows additional information to be added(like the name of the called function, identificationof which argument triggered the error, a clue asto how many iterations had passed, or anything elsethat makes the traceback more informative).Python code has a number of cases where a higherlevel routine traps an exception and reraises it withnew information and losing the lower level errordetail in the process.Raymond Hettinger

• Previous message:[Python-Dev] the new 2.3a1 settimeout() with httplib and SSL
• Next message:[Python-Dev] Idea for avoiding exception masking
• Messages sorted by:[ date ][ thread ][ subject ][ author ]