Application-Wide Unhandled Exception Catcher

[zachattack05]

Quick question.

A few of the commercial/closed source applications I use contain an external exception handler or crash catcher and I am wondering if anyone has ever implemented something like this and would be willing to discuss the use of such a method of exception handling?

Basically the way it appears to work is, when an application runs another application also runs separately but monitors the first watching for crashes. When an exception occurs that causes the first application to take a nose dive, the second application "catches" the exception, displays the standard "Sorry, this application died, here is some information you probably can't use...do you want to send this error to our tech support staff with a short description of what you were doing when the application died?" If the user says yes, the crash-catcher generates a text or some other type of object file that the user can either electronically transmit to the technical support staff at the company that produced the software via the internet or if no internet connection is available at the time of the crash, it saves the file to disk to be quietly transmitted later on when an internet connection is available or for the user to email to the tech support people.

Obviously the goal of any application is to handle any exception quietly and to make the user's life easier, but hey, let's face it, sometimes things are missed or overlooked.

So, I'm wondering a few things...

• I'm guessing that the main application would start the crash-catching application on startup, providing some information for it to monitor the correct application.
• How would it be possible for the main application to send the exception and other data to the crash-catching application if...well, it crashes? Obviously, if a crash or unrecoverable exception occurs and the application truly crashes, it ceases to function and closes, preventing it from sending or doing anything, so for that to work, there would need to be some sort of logic somewhere that says "if there's an exception that isn't handled, send the exception object to this other application and close."
• The other option, I'm guessing, would be for the crash-catcher to monitor something else without input from the main application and there would need to be some kind of way for it to know something didn't work right and to get as much info as it can from whatever source it is monitoring.

The reason I am contemplating this is because try/catch blocks make me nervous that if I forget to cover all of the possible exceptions, or fail to use a try/catch, that a user is going to have a problem performing some task and with that try/catch block potentially ignoring/not catching an error or missing one and not providing any useful information, I might not be able to fix it.

Any thoughts?

[Philippe.Lahaie]

static void Main()
{
    try
    {
        //run application
    }catch(Exception e){
        MessageBox.Show("This Exception was not handled : " + e.Message);
        //or lauchn error sending program with details from e
    }
}

[zachattack05]

Thanks for your reply Philippe.Lahaie!

Are there any downfalls of using such a method? I've considered this exact method, but wasn't sure if there were any issues with using such a method?

[Philippe.Lahaie]

not that i am aware of, the safest way is always gonna be to handle your exceptions correctly, but if any manage to slip by, this would be an efficient way to safely "crash".

[thines01]

Logically, some type of notification would happen upon the global exception that would tell a responsible party the program had an abnormal end.

If the program has any importance, you'll probably want tighter control on WHERE the exception happens.

As you implied:
For a small program, this would not be too bad, but an error like "The input string was not in the correct format" that happens somewhere inside a 1000+ line program is not very helpful. You will still need to spend the time hunting down the real error.

One of the best benefits of coding is that it can prevent you from having to do the "work" (once you've told/enabled the code to do it).

With that said:
If you are using someone else's library and they have not properly handled exceptions (or notifications), you should do whatever is necessary. ...but don't rule out getting a better library.

[Philippe.Lahaie]

even with just one Execption catching mechanism in the main method, which isnt really what we were suggesting, it would still be doable to pin point the culprit code if the exception throwing code does it's job well, either add information to existing Exceptions or plain use CustomExceptions.

Although I am not sure how big of a difference it would be performance wise between handling errors with errorcodes and messages versus throwing custom exceptions and handling them, i find the latter rather elegant code wise.

But i believe try catch blocks are heavy on the processors and are to be avoided when possible in a strickly performance stand point, all of this is out of memory though i do not have any sources to quote for this.