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!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: Wed, 17 Jan 2007 17:35:46 -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> <1lpy2h06scx34.1i2k4dlbg0nfy.dlg@40tude.net> Subject: Re: Structured exception information Date: Wed, 17 Jan 2007 17:36:41 -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-O7UevhOxJpuc1rfqxttOZdDmQXuPn7hglk8j6apASdGJtFmUs3v/gmHjoDdTikWW2046JxcJsndN8J1!zkvhzKry+uiOu3he1eNFKq7lc1VFvNE73lLv6+cGhYl9JxylqyntlgkYtQO18RGZbXyua5hqkME6!EXg3OENbCnivPA== 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:8239 Date: 2007-01-17T17:36:41-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:1lpy2h06scx34.1i2k4dlbg0nfy.dlg@40tude.net... > On Tue, 16 Jan 2007 16:52:31 -0600, Randy Brukardt wrote: > ... > > 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. Sure? You can never be completely sure; you have to mitigate risks. But in my case, I trust my compiler not to destroy anything before generating checks (given that I wrote most of the compiler, I have a lot of knowledge of what it will and will not do). I also build components to be resilient to failure: most everything is controlled, and will reset itself to a correct state if the objects are prematurely finalized. The main remaining risk is using dangling pointers (and I try to avoid pointers as much as possible, and use a special storage pool to try to detect that when I cannot avoid it). An implementation that corrupted something on a failure is just not acceptable. But even with the logging, you still have to be able to deal with crashes. For instance, these programs run on Windows; and it's been known to die occassionally. So the mail server has to guard against that, too. Since, because mail should never, ever be lost, most everything in memory is also mirrored on disk: a mail message is written to disk before a successful receipt is acknowledged, and it stays there until a successful receipt by the destination is acknowledged. So, there is a tiny chance that mail might be sent twice, but virtually none that it would be sent never. At least in this case, the program can be restarted with little negative impact. The main problem is that if it fails when no one is around, it could be a long time before anyone is able to restart it. I think there are a lot of programs in that category - that is, very important, but not loss-of-life crticial. > 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. Well, then there are no bugs in my mail and web servers. I'm happy to hear that. ;-) That doesn't match my definition of bug. There's not much to talk about if we don't agree on the meaning of basic terms. Randy.