How to pop the interpreter's stack?

[Robert Kern]

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"<ethan at stoneleaf.us>  wrote in message
>>> news:mailman.4.1292379995.6505.python-list at 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