Perl is worse!

Martijn Faassen m.faassen at vet.uu.nl
Mon Jul 31 04:27:21 EDT 2000


Steve Lamb <grey at despair.rpglink.com> wrote:
> On 30 Jul 2000 21:33:13 GMT, Martijn Faassen <m.faassen at vet.uu.nl> wrote:
>>condition. It cannot magically repair bugs. So what is you want?

>     A little tolerance to those bugs, not a panic to break out of a 12 deep
> nested loop to a point of no recovery while in the /customers/ hands.  

Then catch exceptions. Or make your code more tolerant of the data in the
first place; let it skip the records that are corrupt. What is the problem?

Really, your advocacy for more tolerance of bugs so that:

  * the program keeps running (even though it may be doing all the wrong
    things)

  * there is a possible (but impossible to predict!) chance of recovery of
    some data in interactive software.

is really bizarre to me. What kind of software engineering attitude is that?
If you want such tolerance, put it in your code. That's fine if it is
in your requirements. But often it is *not* in requirements, in which case
you seem to say it should be anyway. That is bizarre in the face of the
examples you've been given.

>>And what is your experience regarding databases and exceptions in Python?

>     As Alex pointed out there are more databases than just that.  

Yes, sure, but you were claiming exceptions and Python somehow made
the picture worse. I just gave you examples where in the case of
relational databases, it didn't, and in the case of the object database,
it made it *better*.

In the case of fragile databases, your bug-tolerant software has a higher
chance to corrupt things and/or create data-loss than software that craps out
on the first sign of something amiss, I'd say (especially since the crap-out
handler can be made to do something sane with the data).

Regards,

Martijn
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?



More information about the Python-list mailing list