On 12/16/10 10:23 AM, Steven D'Aprano wrote:
On Thu, 16 Dec 2010 07:29:25 -0800, Ethan Furman wrote:

Tim Arnold wrote:
"Ethan Furman"<et...@stoneleaf.us>  wrote in message
news:mailman.4.1292379995.6505.python-l...@python.org...
kj wrote:
The one thing I don't like about this strategy is that the tracebacks
of exceptions raised during the execution of __pre_spam include one
unwanted stack level (namely, the one corresponding to __pre_spam
itself).
[...]
A decorator was one of the items kj explicity didn't want.  Also, while
it would have a shallower traceback for exceptions raised during the
__pre_spam portion, any exceptions raised during spam itself would then
be one level deeper than desired... while that could be masked by
catching and (re-?)raising the exception in the decorator, Steven had a
very good point about why that is a bad idea -- namely, tracebacks
shouldn't lie about where the error is.

True, very true... but many hours later, it suddenly hit me that what KJ
was asking for wasn't *necessarily* such a bad idea. My thought is,
suppose you have a function spam(x) which raises an exception. If it's a
*bug*, then absolutely you need to see exactly where the error occurred,
without the traceback being mangled or changed in any way.

But what if the exception is deliberate, part of the function's
documented behaviour? Then you might want the exception to appear to come
from the function spam even if it was actually generated inside some
private sub-routine.

Obfuscating the location that an exception gets raised prevents a lot of debugging (by inspection or by pdb), even if the exception is deliberately raised with an informative error message. Not least, the code that decides to raise that exception may be buggy. But even if the actual error is outside of the function (e.g. the caller is passing bad arguments), you want to at least see what tests the __pre_spam function is doing in order to decide to raise that exception.

Tracebacks are inherently over-verbose. This is necessarily true because no algorithm (or clever programmer) can know all the pieces of information that the person debugging may want to know a priori. Most customizations of tracebacks *add* more verbosity rather than reduce it. Removing one stack level from the traceback barely makes the traceback more readable and removes some of the most relevant information.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to