Re: General exception Handling question

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On Sat, 26 Jan 2008 13:17:44 -0800, BlackWasp <nospam@please> wrote:

I agree with most of the points discussed so far but would add one point specifically for GUI applications. If the GUI holds important information for the user that may not have been saved, it is a good idea to let the application remain active even if it is ust to let the user do the last-ditch action of copying the data to the clipboard.

Frankly, while I see the value in the idea behind that goal, it's not a very practical, or even safe, thing to try. Or at least, to provide as a general suggestion. If you have designed the entire UI layer of the application with this in mind, then yes...it's theoretically possible to provide the user with a last-ditch "copy selection" minimal UI for cases like this. If all the application uses is built-in controls like TextBox, it might even not require a lot of extra code.

But regardless of the amount of extra code required, it's not going to be simple to ensure that the user can _only_ do the minimal actions required to copy and paste data, and if you've got any sort of custom UI yourself, not only does the work required to handle something like this go up by quite a bit, you have no way of knowing that the exception isn't being caused in that custom code, leading the user down a frustrating tease with no end.

To retro-fit an existing application with this sort of behavior is to invite all sorts of new problems in the code, not only in the handling of the exception scenario, but also providing new avenues for failure in the common-case, non-failure scenarios. For example, it provides a whole new possible bug in which the user cannot do anything except copy and paste the code, even if the program hasn't otherwise failed.

I have had users in the situation too often where they can see the data that they desperately require but only behing the dialog box that is telling them that the application is going to close.

I too have seen programs that do this. But as frustrating as that might be to the users, that's not really an argument for further complicating the program and adding a whole new layer of potential bugs. The effort would be better spent simply ensuring that the original code is well-designed, well-written, and well-tested so as to avoid the need for this sort of thing in the first place.

The fact is, if this sort of thing comes up with anything even _approaching_ regularity, no sane user is going to want to use the program anyway. So either you've got a program with way too many bugs (and if so, what hope do you have of correctly dealing with the exception scenario either?), or you've got clients who value their data so highly that even a single crash per year causes an unacceptable loss (in which case, you should simply deliver better code, and charge the customer the additional cost that is incurred to design, implement, and test the code better, and which is justified by their needs).

I remember this with many shrick-wrapped packages in Windows 3.1. The "The application has failed and should be closed." type errors gave you that get-out clause.

I remember a lot of crashes in Windows programs. Heck, I still see too many Windows programs that are poorly written and crash too often. But it's very rare when I see a program that tries to allow you to actually extract data from an application that is on its way down. In fact, I can't think of a single mainstream application that does this.

...or alternatively, make sure that your application saves data as it goes and is able to recover on re-loading, in a similar manner to Microsoft Word.

Auto-save can be nice, but it would be better to not need it in the first place and again, the question is begged, if the authors of the program can't keep it from crashing, just how reliable can we expect auto-save to be? The most useful scenario for auto-save is actually situations where the application has no control (for example, the whole computer locks up because of a driver bug, or something like that). As a feature, it's not really a solution to potential crashes...it's more for dealing with other things that are outside the application's control.

IMHO, one of the biggest problems with software design is complexity. If your concern is that of dealing with program errors, the solution is definitely _not_ to increase complexity. I just do not see global exception handling as a serious approach to program correctness.

Pete
.

Relevant Pages

  • Re: Highlighting blanks via GO TO SPECIAL is not highlighting blank cells - HELP, Im totally stu
    ... Then I can sort by anything I want. ... helper column ... > Finally found the bug reporting page by signing in with Passport, ... is a wildcard that represents any one character. ...
    (microsoft.public.excel.misc)
  • Re: {OT} outlook express users
    ... The one thing it doesn't fix is OE's bug of stripping OT: ... And I particularly like the sort feature, ... the first non-whitespace character following the colon. ... If you strip off ...
    (alt.autos.toyota)
  • Re: Recycle bin sorting error
    ... >to the Recycle Bin the sort order is screwed up. ... And the bug shows ... for 5-10 minutes at a stretch when he went to talk to his manager. ...
    (microsoft.public.windowsxp.general)
  • Re: sort bug?
    ... It's very important to be clear about what the bug is here. ... and the linux machine is running 7.0.0. ... On my mac, if I get the following results when sorting the array ... help documentation for sort states: ...
    (comp.soft-sys.matlab)
  • Re: smuggling data in and out of alarm handlers and the like
    ... more likely than a bug in a vendor's qsort() routine that's been used ... it triggered an unstable sort in... ...
    (comp.lang.c)