From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,699cc914522aa7c4 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Structured exception information Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1168885771.30643.20.camel@localhost> <1168891576.30643.39.camel@localhost> <5NKdnTv2UZfVZTbYnZ2dnUVZ_vipnZ2d@megapath.net> <38z8yk9z1uxn$.1r6qpevwu2i7c.dlg@40tude.net> Date: Wed, 17 Jan 2007 09:58:34 +0100 Message-ID: <1lpy2h06scx34.1i2k4dlbg0nfy.dlg@40tude.net> NNTP-Posting-Date: 17 Jan 2007 09:58:34 CET NNTP-Posting-Host: 7c42905f.newsspool1.arcor-online.net X-Trace: DXC=@3P1;N\ifXW@@RW1FjIB5Sic==]BZ:af^4Fo<]lROoRQ^YC2XCjHcbYg6Km>7?DBkQDNcfSJ;bb[UFCTGGVUmh?TN\HXHJ4e80^m55^l<>DLh[ X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:8217 Date: 2007-01-17T09:58:34+01:00 List-Id: On Tue, 16 Jan 2007 16:52:31 -0600, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:s0prxwrhxfj1.1r5zzccgpzy2.dlg@40tude.net... >> On Tue, 16 Jan 2007 17:50:46 GMT, Jeffrey Carter wrote: >> >>> Generally, subprograms should raise exceptions because of precondition >>> violations. If the preconditions are met, the subprogram should not >>> raise an exception (barring things that are beyond the developer's >>> control, such as running out of memory). So it would be better to >>> associate a subprogram with a list of preconditions with the exception >>> raised if each is violated: > ... >> Totally disagree. >> >> A precondition violation is not an exceptional state, it is a bug. Bugs >> fundamentally cannot be handled within the same program. This "exception" >> should propagate in the visual debugger and further into the head of the >> code maintainer, If you want. >> >> The difference becomes obvious if you consider that there might well be >> valid program states corresponding to the end of a file. But there cannot >> be any valid and consistent state in which there would exist x such that >> cosh(x)<1. >> >> Therefore their handling strategies are quite different as well. Bugs >> propagating exceptions is the worst debugging nightmare. A precondition >> violation shall stop immediately to prevent further harm and to make a >> inspection possible. Exceptions are just a method of flow control. > > Yikes. If a precondition failure can be detected statically (i.e. at compile > time), then surely you are right. I doubt that others could or should be called preconditions. > But most of them cannot. And I have a lot of software that shouldn't stop > just because it has a bug. For example, my mail server shouldn't stop > handling mail just because a bug was encountered (and it certainly has had a > few bugs, especially in the spam filter): I want to write the failure into a > special log, save the offending message if possible, reinitialize the task > to a starting state, and continue. Anything else would stop the flow of > mail. How could you be sure that it would write log and not destroy your address database? A vivid example is MS-Word which corrupts the document being edited upon crash. BTW, in my view, writing log is still a valid program state, it is a defined behavior. As long as you can continue, no matter how, it is not yet a bug within the scope where you continue. If cosh(-1) raises an exception, then that is the defined behavior of cosh on -1. If so, then the precondition of cosh cannot exclude -1, because it is a valid argument of. But x /= elephant, for example, is still in the precondition. However, somebody could also define cosh(elephant), which would automatically change the precondition. The point is that violated preconditions are non-states and cannot be handled at all. Provided, that one understands precondition as a method of proving program correctness. Otherwise, it is something else. > Surely there are systems where the best response to a bug is a full stop, > but there are many for which that would be silly. If the airplane or rocket > software shuts down because a bug, at best you'll have vehicle loss (and at > worst, loss of life). It would be a bad design to have a single monolithic software component to control an airplane. The thing should be redundant to provide failover. No malfunctioning component may continue its work (=malfunction!). For example, a CAN bus field controller stops sending anything, when it detects a bus problem. This is the first thing it does. > In any case, you can't draw a hard line between what is a bug and what is > some other sort of error: it can even depend on intended use. A Find routine > that doesn't find anything could be an error or could be expected -- and we > don't have different otherwise identical routines for this purpose. Yes. The semantic of a program is defined by its developer. The same program can be wrong and right. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de