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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Tue, 16 Jan 2007 16:51:34 -0600 From: "Randy Brukardt" Newsgroups: comp.lang.ada References: <1168885771.30643.20.camel@localhost> <1168891576.30643.39.camel@localhost> <5NKdnTv2UZfVZTbYnZ2dnUVZ_vipnZ2d@megapath.net> <38z8yk9z1uxn$.1r6qpevwu2i7c.dlg@40tude.net> Subject: Re: Structured exception information Date: Tue, 16 Jan 2007 16:52:31 -0600 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Message-ID: NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-UhpgwPX1EgB8j68MaIUCgPkovZdd0ObjKdh8j4hiOnrJ1b5CEL0hKwk7dbeb6j3rb3B2qN3xZcUKRYN!dSsEKtwc3caWh1/7S+TPcG5Gi/TSHqR9/uegsA6kv6J5Fb0auwWkfnzlGeVjev7sSi1I/ji9vYR4!Vo5i0jGJXqNGlw== X-Complaints-To: abuse@megapath.net X-DMCA-Complaints-To: abuse@megapath.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news2.google.com comp.lang.ada:8205 Date: 2007-01-16T16:52:31-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:s0prxwrhxfj1.1r5zzccgpzy2.dlg@40tude.net... > On Tue, 16 Jan 2007 17:50:46 GMT, Jeffrey Carter wrote: > > > Dmitry A. Kazakov wrote: > >> > >> procedure Foo raises Foo_Error; -- Compile error! > > > > 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. 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. 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). 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. Randy.