GUI application death catcher?

[Peter Hansen]

Douglas Alan wrote:
> 
> Peter Hansen <peter at engcorp.com> writes:
> 
> > 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.

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? :-)

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

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