Re: Structured exception information

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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.