Return to BSD News archive
Xref: sserve comp.unix.programmer:25527 comp.lang.c:100410 comp.bugs.4bsd:2076 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!yarrina.connect.com.au!classic.iinet.com.au!news.uoknor.edu!news.ecn.uoknor.edu!paladin.american.edu!europa.chnt.gtegsc.com!howland.reston.ans.net!news1.digex.net!news3.digex.net!access5!wboyce From: wboyce@access5.digex.net (Willis B. Boyce) Newsgroups: comp.unix.programmer,comp.lang.c,comp.bugs.4bsd Subject: Re: qsort w/trivial compare functions doesn't terminate Followup-To: comp.unix.programmer,comp.lang.c,comp.bugs.4bsd Date: 14 May 1995 23:44:04 GMT Organization: Express Access Online Communications, USA Lines: 28 Message-ID: <3p64k4$ed2@news3.digex.net> References: <3l23i4$l34@agate.berkeley.edu> <3lotvs$hcf@post.gsfc.nasa.gov> <D6MI4r.F08@proteon.com> <3m1f65$4md@hermes.unt.edu> <3m48il$edh@paperboy.osf.org> NNTP-Posting-Host: access5-2.digex.net X-Newsreader: TIN [version 1.2 PL2] Rich Salz (rsalz@osf.org) wrote: : Given the poor state of error-detection most programmers do, terminating : a program with a coredump rather then returning a status code that says : "failed, you gave me NULL rather then a valid pointer" is often better. : Coredumps stand a much better chance of being found, and fixed. I share your fatalistic attitude toward program errors. There are, IMHO, two sorts of errors. The first are user-related errors. The user has, for instance, requested a file that does not exist, or tried to cause the program to allocate more memory than is available. These are generally recoverable because the program can just undo whatever the user was trying to do, then return to the interactive state (or quit, if the program is noninteractive). The majority of errors, however, are of the second sort, namely, errors in which some particular thing that the program needs in order to continue processing is unavailable or is in an incorrect state. In the event of these errors, I always abort. For instance, if I write a file to the disk, then try to read it back a little while later and find it missing, I'm not going to waste my time and the computer's time trying to recover. Something is clearly wrong, and an operator should be notified. Similarly, if I'm writing a library of some sort, and somebody passes me a bogus handle of some sort, obviously the programmer has a problem with his or her application and needs to be made aware of that fact. Calling abort accomplishes this nicely, and leaves a core file that can be examined in the debugger. Better a little downtime, IMHO, than lossage. Will