centralize way of exception handling

[Noor]

Hi all,

I am trying to catch all types of exceptions from a app regardless of
whether it is in debugger mode( VS development environment) or run the.exe
file outside the IDE.


My App contains the thousand of classes and I do not want to use the Try
Catch block in each class. Because it is logically similar to GOTO
statement. I want to prevent exception from being swallowed.



I use a startup project, so that i can show the MDI main application window
within a Try Catch block. This all works fine when i run the App from within
the IDE, but when i run outside of the IDE i.e. run the .exe file. It
doesn't seem to catch the exception???



I also use both Application.ThreadException and
AppDomain.CurrentDomain.UnhandledException event in order to capture
unhandled Exceptions outside the IDE.



Now please guide me whether it is good technique for centralize way of
exception handling or I need two startup classes to handle Exception. One
for handling Exception within the IDE and one for outside the IDE.



Here is my sample code for handling all types of exception within one
startup class.

try {

Application.ThreadException += new
ThreadExceptionEventHandler(App_ThreadException);

AppDomain.CurrentDomain.UnhandledException +=new
UnhandledExceptionEventHandler(App_UnhandledException);

Application.Run();

} catch(Exception ex) {

//write nice error reporting routine!

Environment.Exit(0);

}

private static void App_ThreadException(object sender,
ThreadExceptionEventArgs e) {

//show message Box

}

private static void App_UnhandledException(object
sender,UnhandledExceptionEventArgs e) {

//show message Box

}

Hope this makes sense.

Waiting for your reply.

thanks inadvance.

Regards

Noor

 

[Bruce Wood]

Yes... using Application.ThreadException and
AppDomain.Unhand­ledException is the MS recommended way of doing
global exception handling. You are doing the right thing.

I went one step further and created a separate Singleton class called
"ErrorLog" that applications can call to set up error handling.
ErrorLog offers different static methods to set up different error
handling for Windows applications, Console applications, and Windows
services applications. It also sets up error handlers only when the
application is not running under the debugger, because when you're in
the debugger you _want_ exceptions to percolate to the top so that the
debugger can break on the excpetion point.

The methods in ErrorLog look like this:

public void MessageBoxLogAndAbortUnhandledExceptions(string
logFilePath)
{
if (!System.Diagnostics.Debugger.IsAttached)
{
this.errorLogFilePath = logFilePath;
Application.ThreadException += new
ThreadExceptionEventHandler(this.OnThreadExceptionMessageBoxLogAndAbort);
AppDomain.CurrentDomain.UnhandledException += new
UnhandledExceptionEventHandler(OnUnhandledExceptionMessageBoxLogAndAbort);
}
}


private void OnThreadExceptionMessageBoxLogAndAbort(object sender,
ThreadExceptionEventArgs te)
{
ExceptionMessageBoxLogAndAbort(te.Exception.ToString());
}

private void OnUnhandledExceptionMessageBoxLogAndAbort(object sender,
UnhandledExceptionEventArgs ue)
{
Exception ex = ue.ExceptionObject as Exception;
if (ex == null)
{
ExceptionMessageBoxLogAndAbort(String.Format("Exception: {0}, Text:
'{1}'", ue.ExceptionObject.GetType(), ue.ExceptionObject.ToString()));
}
else
{
ExceptionMessageBoxLogAndAbort(ex.ToString());
}
}

private void ExceptionMessageBoxLogAndAbort(string msg)
{
DialogResult result = DialogResult.Cancel;
try
{
string message = "An error occurred. Please contact IS with the
following information:\n\n" + msg;
result = MessageBox.Show(message, "Application Error",
MessageBoxButtons.OK, MessageBoxIcon.Stop);
}
catch
{
// Really nothing to do here... couldn't show a message
// box, so no recovery is possible. Just catch the exception
// and move on....
}
finally
{
try
{
Log(msg);
}
catch
{
try
{
MessageBox.Show("Could not write to log file " + this.LogFilePath,
"Fatal Error", MessageBoxButtons.OK, MessageBoxIcon.Stop);
}
catch
{
// Really nothing to do here. Just absorb the exception.
}
}
finally
{
Application.Exit();
}
}
}