How to pop the interpreter's stack?

Steven D'Aprano steve+comp.lang.python at pearwood.info
Thu Dec 23 23:55:09 EST 2010


On Thu, 23 Dec 2010 02:54:52 -0800, Carl Banks wrote:

> On Dec 22, 7:22 pm, Steven D'Aprano <steve
> +comp.lang.pyt... at pearwood.info> wrote:
>> There should be a mechanism for Python functions to distinguish between
>> unexpected exceptions (commonly known as "bugs"), which should be
>> reported as coming from wherever they come from, and documented,
>> expected exceptions, which should be reported as coming from the
>> function regardless of how deep the function call stack really is.
> 
> No, -100.  The traceback isn't the place for this.  I've never disagreed
> with you more, and I've disagreed with you and awful lot.

Okay, it's your right to disagree, but I am trying to understand your 
reasons for disagreeing, and I simply don't get it.

I'm quite frustrated that you don't give any reasons for why you think 
it's not just unnecessary but actually *horrible* to hide implementation 
details such as where data validation is performed. I hope you'll try to 
explain *why* you think it's a bad idea, rather than just continue 
throwing out dismissive statements about "self-important" programmers 
(your earlier post to KJ) and "never disagreed more" (to me).

Do you accept that, as a general principle, unhandled errors should be 
reported as close as possible to where the error occurs?

If your answer to that is No, then where do you think unhandled errors 
should be reported?


Now, given the scenario I proposed earlier:


>>> f('bad input')    <=== error occurs here
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in f
  File "<stdin>", line 2, in g
  File "<stdin>", line 2, in h
  File "<stdin>", line 2, in i
  File "<stdin>", line 2, in j
  File "<stdin>", line 2, in k    <=== far from the source of error
ValueError


do you concede that the actual error occurs at the time 'bad input' is 
passed to f, and not further down the stack where k happens to raise an 
exception? If not, where do you think the error occurs, and why?



-- 
Steven



More information about the Python-list mailing list