Re: Structured exception information

On Wed, 17 Jan 2007 17:36:41 -0600, Randy Brukardt wrote:

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:1lpy2h06scx34.1i2k4dlbg0nfy.dlg@xxxxxxxxxxxxx

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.

Consider a failure defined as "corrupting something." Now what an
implementation should do if it notices that it just has corrupted something
(=failed)? (:-))

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.

Right. This is exactly the point. When MS-Word crashes it is not a crash of
Windows. Thus the program Windows can continue, the file system can, HDD
can, the powerplant supplying the computer can etc, but MS-Word cannot. In
other words, for Windows it is a normal state when MS-Word crashes... (:-))

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. ;-)

An undesired behavior is still one... Otherwise we would considered
anything we don't like as bugs.

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.

Yes. I think one should clearly distinguish:

1. states
2. undesired (exceptional) states
3. non-states (bugs)

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • RE: Reading on Win2K corrupts WinXP encrypted file?
    ... running Windows XP SP1 or Windows Server 2003. ... Reading on Win2K corrupts WinXP encrypted file? ... describing the different default encryption ... methods for Win2K, WinXP Gold, and WinXP SP1. ...
    (microsoft.public.win2000.security)
  • Re: Creating Wrappers around Window Programs.
    ... windows application that would help out with the word completion feature as ... It is possible, in principle, to watch the Windows message queue: ... to develop) can modify the UI as well while performing the word completion. ... that he "intends" to type on his Windows application(such as MS-WORD). ...
    (microsoft.public.word.vba.customization)
  • Re: blasterworm
    ... > windows xp, as it corrupts 3ds max files, is this true ... Windows Explorer Quits Unexpectedly or You Receive an Error Message When You ... Microsoft MVP Scripting and WMI, ...
    (microsoft.public.security.virus)
  • Re: Mildly OT: dBASE IV
    ... again MS-Word wasn't perfect either but at least ... I think there were a couple of problems with WordPerfect for Windows ... Using WPWin on a machine with 2Mb of memory was interesting ... and printer manufacturers were keen to provide new WP ...
    (comp.databases.theory)
  • Re: =?iso-8859-1?q?Textverarbeitungsm=F6glichkeit_f=FCr_Runtimeprogramm?=
    ... kommt nicht in Frage, da nicht sichergestellt ist, dass bei den Usern ... MS-Word vorhanden ist. ... (Ich arbeite mit Access2003 unter Windows XP) ... Kennt jemand eine Internetadresse, an der ich mir einen Editor in ...
    (microsoft.public.de.access)