Re: How to pop the interpreter's stack?



On Dec 23, 8:55 pm, Steven D'Aprano <steve
+comp.lang.pyt...@xxxxxxxxxxxxx> 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...@xxxxxxxxxxxxx> 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
.



Relevant Pages

  • Re: Problem with "handles" - possible garbage collection issue?
    ... | The symptom that users report is that after they have been using the ... You may want to include one or more Global Exception handlers in your ... Use AddHandler in your Sub Main. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Finding Error in Applet.
    ... If you report the situation inaccurately, advice given will be inaccurate and likely useless. ... Sometimes 1 in 10 times it hangs. ... If an Exception or Error or any other Throwable were thrown, you'd have gotten a message to that effect already. ... A good logging package, like the inbuilt java.util.logging package or the open-source log4j library, can report the type of information you seek. ...
    (comp.lang.java.programmer)
  • Re: cannot access IE
    ... We have created an error report that you can ... >> vendor code, bla bla. ... Module 1 Image base, Image ...
    (microsoft.public.windows.inetexplorer.ie6.browser)
  • Re: cannot access IE
    ... We have created an error report that you can ... >> vendor code, bla bla. ... Module 1 Image base, Image ...
    (microsoft.public.windows.inetexplorer.ie6.browser)
  • XLANGPart.LoadFrom(stream) failing - UnauthorizedAccessException
    ... My component then generates a PDF stream using Crystal Reports, ... attempts to load the XLANGMessage's 1st data part with the stream generated ... ReportDocument report = new ReportDocument; ... Exception thrown from: segment 1, ...
    (microsoft.public.biztalk.general)