GUI application death catcher?

Discussion in 'Python' started by Douglas Alan, Feb 18, 2004.

  1. Douglas Alan

    Douglas Alan Guest

    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
     
    Douglas Alan, Feb 18, 2004
    #1
    1. Advertising

  2. Douglas Alan

    Peter Hansen Guest

    Douglas Alan wrote:
    >
    > 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
     
    Peter Hansen, Feb 19, 2004
    #2
    1. Advertising

  3. sys.excepthook will probably be your friend.

    - Josiah
     
    Josiah Carlson, Feb 19, 2004
    #3
  4. Douglas Alan

    F. GEIGER Guest

    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

    "Douglas Alan" <> schrieb im Newsbeitrag
    news:...
    > 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
     
    F. GEIGER, Feb 19, 2004
    #4
  5. Douglas Alan

    max khesin Guest

    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?
     
    max khesin, Feb 19, 2004
    #5
  6. Douglas Alan

    Douglas Alan Guest

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

    > 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
     
    Douglas Alan, Feb 19, 2004
    #6
  7. Douglas Alan

    Peter Hansen Guest

    Douglas Alan wrote:
    >
    > Peter Hansen <> 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
     
    Peter Hansen, Feb 20, 2004
    #7
  8. Douglas Alan

    Douglas Alan Guest

    Peter Hansen <> 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
     
    Douglas Alan, Feb 20, 2004
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. morc
    Replies:
    6
    Views:
    5,260
    Hal Rosser
    Feb 10, 2006
  2. jwaixs

    website catcher

    jwaixs, Jul 3, 2005, in forum: Python
    Replies:
    9
    Views:
    1,482
    =?ISO-8859-1?Q?Michael_Str=F6der?=
    Jul 6, 2005
  3. robert
    Replies:
    0
    Views:
    315
    robert
    Jun 7, 2006
  4. Adrienne Boswell

    Completely OT - Rolo the Mouse Catcher

    Adrienne Boswell, Jan 10, 2009, in forum: HTML
    Replies:
    10
    Views:
    736
    Neredbojias
    Jan 12, 2009
  5. asim malik
    Replies:
    1
    Views:
    251
    Martijn Lievaart
    Sep 13, 2009
Loading...

Share This Page