Re: Python or Perl for a Debian maintainance project?
Andrew Suffield <asuffield@debian.org> writes:
> On Sun, Feb 22, 2004 at 10:39:56PM +0100, Florent Rougon wrote:
>> Any sane programmer knows that silent errors are the worst thing they
>> can face, because you don't know precisely when they happen (by
>> definition, since they are silent), but the program is malfunctioning,
>> or breaks other software while it is very difficult to find the cause;
>> because it is indirect; because the program didn't abort when the error
>> took place; because you are unable to reproduce the bug.
> Any experienced programmer knows that it is better to not crash than to
> crash.
Er, well, I don't really agree with either of you. Large projects like
GCC tend to categorize failures with the following hierarchy:
1. Silent data corruption. This is the worst, and I think this is what
Florent is getting at. This is far worse than crashing.
2. Bizarre or confusing error message and fatal exit. For the average
user, Python exceptions, C segfaults, Java exceptions, Perl errors
like undef used as an object (which I've seen when errors weren't
checked), and the like are all pretty much equally confusing, IMO,
although C segfaults are perhaps more obviously cryptic. If you *have*
to crash, it's probably better to spew an accurate backtrace than to
just print some bizarre (from the user perspective) error message like
"segmentation fault", but really one is just bickering over details
at that point. Either way, it's a bug.
3. Bizarre or confusing warning messages, but the program continues to do
something plausible. Perl scripts run under -w tend to fall into this
category when they don't handle errors properly and don't guard against
undef data, but the error doesn't cause data corruption.
4. Silent continuation with plausible actions, without reporting the
error. This is still a bug, of course, since something's wrong that
wasn't expected and the user may be surprised by the output.
I think part of this debate is about classifying errors into 1 or 3.
There's also a separate debate (not really touched on here) about the
relative merits of 3 and 4; 3 provides more information for the
experienced programmer to identify the problem, but baffles the user more.
3 can also cause problems if the error messages are massive (I've seen
Perl scripts that will spew megabytes of undefined value warnings because
of one missing test, since it was in the middle of a tight loop).
It seems like Florent is very worried about 1, which is understandable
because 1 is the worst case scenario. It seems like Andrew is trying to
point out that in his experience many Python programs end up doing 2,
whereas in practice it's pretty rare to find even a badly written Perl
program that actually does 1 rather than doing 3 or 4.
For whatever it's worth, my experience backs up Andrew in that 1 is pretty
rare even with Perl programmers who don't know what they're doing, but I
can see the point that Python's error handling model makes it much more
difficult for 1 to happen in unforseen circumstances. In other words,
Python tries to protect against 1 in exchange for escalating many errors
that would have been of type 3 or 4 in Perl or C to type 2 instead.
Oh, and my experience is that the really *horrible* language for tons of
type 2 errors all over the place is Java. Python coders and programs are
wonderfully clean by comparison.
Don't know if this helps any. It just felt to me like both sides had
valid points and were largely talking past each other.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
Reply to: