Re: Terminating program in ProcessWndProcException

From: Martin Aupperle (XXXMartin.Aupperle_at_PrimaProgrammXXX.de)
Date: 08/30/04 

Date: Mon, 30 Aug 2004 15:29:34 GMT

On Sat, 28 Aug 2004 12:46:05 -0400, Joseph M. Newcomer
<newcomer@flounder.com> wrote:

>Philosophically, NO program should terminate except by user directive. When I get problems
>like this, I simply enter a mode in which most of the menu items are disabled. One of the
>few that is still active is Program>Exit, and I usually have a few diagnostic menu items
>that either become enabled or appear magically.

If this works for all of your exceptioanl situations, you then you are
lucky.

For all of our exceptional situations, we simply bring up a dialog
that has lots of information about the situation, the context, etc.
The user can dump that to file, send it via email, or print ist. This
is clear and undisputed.

The interesting thing is what happens after the user closed the
dialog. Most of the time, the program can continue, especially when
the problem arose in a command handler (user pressed a button, user
selected a menu item etc. ). Our command handlers are "exception
safe", i.e. the program is in a defined state even if the command
handler exits through an exception. That was the easy case - more than
90% of our exceptional situations fall into this category.

The difficult ones are things like "the creation of necessary central
data structures failed" "memory shortage (i.e. new/malloc failed)",
"heap corruption (i.e. AfxIsValidAddress failed)" and some others. We
consider these severe enough to abort the program immediately after
the user quits the info-dialogbox.

>
>Do not call _exit. Do not call _abort. The problem with all such "recovery" mechanisms is
>that besides doing more harm than good, they aren't defined for Windows apps.

Well, depends. They work well in other situations. E.G. you can call
them from command handlers (you should not, but you can). They simply
do not work in ProcessWndProcException.

>Posting WM_QUIT won't help, because ;you probably don't have a message loop running at
>that point.

Why not? I thought I always have a message loop running - at least
until a WM_QUIT gets processed. ProcessWndProcException gets called
when an exception of type CException* gets thrown during message
processing and not catched earlier.

>
>A more serious question is where are these exceptions coming from? If they are exceptions
>you are throwing, that's fine. But if they are exceptions being thrown by the runtime in
>some way, they should be fixed.

We distinguish between "locgic errors" and "runtime errors".

Logic errors are failed preconditions, ASSERTs and that kind of stuff.
If such an exception gets thrown, we know that we have made a
programming error which must be fixed, and a new software version
released. Nevertheless - no software of the size of ours is error
free, so we
 1. must present the user with some information about an "internal
error" , as we like to call it.
2. allow the user to send us information about that, so that we can
fix it.

Please note that this is more than most programs do when a programming
error hits. They simply crash.

Runtime Errors are situations of mostly transient nature that go away
with time, or need some administrator intervention, rebooting or
reinstallation etc. E.G when the network chokes, or the database
becomes unreachable in the middle of a transaction. Memory exhaustion
or out of Windows resources also belongs to that category.

So, if "the runtime" throws an exception, it really depends.

>
>My exception loop was something like
>
>int MYApp::Run()
> {
> while(true)
> { /* main loop */
> try
> {
> return CWinApp::Run();
> }
> catch(...specific exception...)
> {
> }
> catch(...other exception....)
> {
> }
> catch(...)
> {
> }
> } /* main loop */
>}

I did this once too, but a little different. I completely overloaded
Run and had my own message loop. I wanted to have all exceptions
handled WITHIN the loop.

The advantage compared to overloading ProcessWndProcException is that
we can catch exceptions that are not derived from CException. When
using external libraries that throw this definitely in an advantage.

But the question remains: how can I terminate the program from within
ProcessWndProcException?

[snip]

>
>There is nothing more confusing to a user than having a program spontaneously exit. There
>is nothing harder for tech support to deal with than a program that merely exits.
>
>By continuing to run, I was able to add diagnostics and reporting mechanisms that would
>allow tech support todiagnose the problem. This was important, because the libraries we
>used would throw random exceptions. Putting an exception frame at every call was too hard
>(hundreds of calls). Once I started catching exceptions like this, we could target our
>handlers to do better recovery in key places.

We are not so far apart from each other. I do this "diagnostics and
reporting" too, but I do the diagnosting at the throw location and the
reporting at the catch location (in an appropriate dialog).

Martin

------------------------------------------------
Martin Aupperle
------------------------------------------------