GUI application death catcher?

[Douglas Alan]

Peter Hansen <peter at engcorp.com> writes:

> In fact, making the GUI a separate program (as I think you might
> have suggested before) is a very good idea, since then you can
> concentrate on getting the failure data safely stored into a file in
> the original program's error handler.

My idea wasn't to make the entire GUI be a separate program (though
that's not a terrible idea, it doesn't solve the problem that the GUI
itself may have bugs) -- just to make the death catcher be a separate
program.  One problem with that idea is that if I do it in Python,
what do I do if I get an exception while doing "import Tkinter"?
That's why I think a statically linked binary would be better for this
particular task.  It seems to me that such death catchers must already
exist.  I can easily write one myself for Unix, but I'm not much of a
Windows expert, and worry that I'll mess up something subtle with
starting up child processes, reading from pipes, waiting for the
child's exit, and the like.

> I'm puzzled though.  Are you really expecting these astronauts,
> brilliant godlike creatures though they must be, to understand
> Python exception tracebacks and modify the source to fix the
> problems?  Or are there some extra levels of translation involved
> here, or is the guy running this going to be the second Python
> programmers in space? :-)

No, the astronaut shouldn't have to know anything about Python.  I
just want to be able to display a message saying something like

     The Session Manager died terribly and then when it tried to log
     the problem to the log file, the operating said that it couldn't
     with the following error message:

        Windows Sucks!

     Please pass on this error message to ground control.

|>oug