How to pop the interpreter's stack?

[Carl Banks]

On Dec 23, 8:55 pm, Steven D'Aprano <steve
+comp.lang.pyt... at pearwood.info> wrote:
> 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?

"No", and "where the error is detected".  That is, what Python does
now.  Trying to figure out where the error "occurred" is fool's
errand.  The former isn't even well-defined, let alone something a
compiler or user can be expected to reliably report.  Sometimes the
error doesn't even "occur" in the same call stack.

There's a similar fine line between a bug exception and bad input
exception, and it's foolish to distinguish them in a reliable way: in
particular bugs can easily be mistaken for bad input.

OTOH, going the extra mile to hide useful information from a user is
asinine.  As a user, I will decide for myself how I want to use
implementation-defined information, and I don't want the implementor
to decide this for me.  It's bad enough if an implementor fails to
provide information out of laziness, but when they deliberately do
extra work to hide information, that's self-importance and arrogance.

The traceback IS NOT THE PLACE for these kinds of games.





> 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?

This question is irrelevant.  It doesn't matter where the mistake is
made.


Carl Banks