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...@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
--
http://mail.python.org/mailman/listinfo/python-list
