[EMAIL PROTECTED] wrote:
>>4. A terminating bug is preferred to a non-terminating bug.
>
>
> This is not self-evident to me. Is this somehow
> related to the design philosophy of functional
> languages? I was never aware of such a preference
> in conventional procedural languages (though I
> could easily be wrong).
>
> It also seems directly counter to Python's "no errors
> should pass silently" dogma -- a non termination
> seems more noticable than silent erroneous results.
You are assuming that the function in question returns
a result *quickly*, and that any delay obvious to the
user is clearly a problem ("damn program has hung...").
Consider a generic function which may take "a long
time" to return a result. How long do you wait before
you conclude it has hung? A minute? An hour? A day? A
month? A year? If you have some knowledge of the
expected running time you can make a good estimate
("well, there are only a thousand records in the
database, so even if it takes an entire minute to check
each record, if it hasn't returned after 17 hours, it
is probably hung"). But for arbitrary problems, you
might not know enough about the function and data to
make that estimate. Some calculations do have to run
for days or weeks or months to get a correct result,
and some are impossible to predict in advance.
So, in general, it is impossible to tell the difference
between a non-terminating bug and a correct calculation
that would have finished if you had just waited a
little longer. (How much is a little longer?) Hence, in
general, a terminating wrong answer is easier to test
for than a non-terminating bug.
--
Steven.
--
http://mail.python.org/mailman/listinfo/python-list
