GUI application death catcher?

[Douglas Alan]

I'm writing a GUI app in Python that will be used on the International
Space Station. I'd like for the app to be as robust as possible and,
consequently, if it crashes, for there to be a log file written and a
coherent error message displayed to the astronaut.

My original approach to this was to write an in-process handler in
Python that would catch all uncaught exceptions and log the error to a
file and then hand-hold the user. This turned out to be a bit hairy
because of all the additional possible errors that might happen while
handling the original error, but I made a decent stab at it.
Unfortunately, I find that as I keep working on the program, I often
break the error handler by breaking some utility code that the error
handler uses. This isn't so good, so it's back to the drawing board a
bit.

One approach I might take now is to maintain duplicate utility
libraries -- one for the error handler and one for the rest of the
code. That way I lessen the risk of breaking the error handler when I
break the rest of the program. Another approach, which is what I am
leaning towards at the moment, would be to have the error handler be a
completely separate process that monitors the application and takes
over if and when the application fails. I would like to write this in
Python, of course, but then I have the worry of what happens if the
Python installation gets bit rot, or something, and the monitoring
program consequently won't run properly. So, now I'm thinking that a
completely stand-alone, statically linked executable would be best for
this particular task.

But I'm really not in the mood at the moment to write a Windows C++
GUI app. (Oh, did I mention that unfortunately this is going to run
on a Windows 2000 machine?) I'm figuring that such programs must
already exist, since there must be a lot of demand for them. In fact,
it seems that when using Windows, I often see pop-up dialogs about how
some program or another crashed and would I like to send a report off
to M$? I'd like the same thing for my app, only for it to send a
report off to me, rather than M$. Does anyone know of a preexisting
(preferably freeware) utility that does what I want?

|>oug

 

[Peter Hansen]

I'm writing a GUI app in Python that will be used on the International
Space Station. I'd like for the app to be as robust as possible and,
consequently, if it crashes, for there to be a log file written and a
coherent error message displayed to the astronaut.

My original approach to this was to write an in-process handler in
Python that would catch all uncaught exceptions and log the error to a
file and then hand-hold the user. This turned out to be a bit hairy
because of all the additional possible errors that might happen while
handling the original error, but I made a decent stab at it.
Unfortunately, I find that as I keep working on the program, I often
break the error handler by breaking some utility code that the error
handler uses. This isn't so good, so it's back to the drawing board a
bit.

This sounds a lot like you are writing this without proper unit tests.
If that's true, and if you really have to run this on a Windows machine,
then god help you...

The only thing I can say that might help beyond that , is that
reliability and simplicity go hand in hand. It sounds like you are
trying to make this error handler more complicated than it should be,
and in the process are making it as or more likely to fail than the
main app might be! Not a good approach. Go with something really
really simple, and if you want to take a stab at a more sophisticated
(read complicated) arrangement, at least put it inside the really simple
handler that you write first and test really well. That gives you
two levels of protection, the one which you hope is all that's needed,
and the other as a last resort in case the first one blows up too.

-Peter

 

[Josiah Carlson]

sys.excepthook will probably be your friend.

- Josiah

 

[F. GEIGER]

Use PyChecker.
Write *extensive* unit tests, as Peter said.
Use sys.excepthook, as Josiah said.
Use the logging module.

It's unlikely that a non-GUI Python app or a Tkinter-GUI Python app crashes
the way that Windows wants to phone home to tell that M$. However, it's more
likely if you use wxPython as your GUI binding. But then you didn't do any
thorough tests.

HTH
Franz GEIGER

 

[max khesin]

I am not sure why you want your error handler to be so complicated that
it has to be coupled with the main program's code. Did you try PyCrash?

 

[Douglas Alan]

This sounds a lot like you are writing this without proper unit tests.
If that's true, and if you really have to run this on a Windows machine,
then god help you...

I do do unit tests, but unit tests for GUI code and I/O are not so
easy.

Go with something really really simple, and if you want to take a
stab at a more sophisticated (read complicated) arrangement, at
least put it inside the really simple handler that you write first
and test really well.

Sure, but really, really simple is nothing more than a pop-up saying,
"The program died", and that's not much more useful than if the app
just disappears, or puts up one of the indecipherable-to-the-layperson
dialog boxes that Tkinter likes to put up when there's an uncaught
exception.

|>oug

 

[Peter Hansen]

I do do unit tests, but unit tests for GUI code and I/O are not so
easy.

Well, much easier for I/O than for GUI, but you've got a point. In that
case, the best advice is to decouple the parts of the problem from each
other. If the GUI can't be easily tested, split it out so that a failure
of the GUI cannot prevent the original exception information from being
lost. 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.

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?

Sure, but really, really simple is nothing more than a pop-up saying,
"The program died", and that's not much more useful than if the app
just disappears, or puts up one of the indecipherable-to-the-layperson
dialog boxes that Tkinter likes to put up when there's an uncaught
exception.

Well, true, but "The program died. Check traceback information stored
in log file." is infinitely better than the app just disappearing, yet
it won't be too hard to make sure that the code that generates this
dialog cannot reasonably fail.

-Peter

 

[Douglas Alan]

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