centralize exception handling without try catch blocks in c#.

[Noor]

please tell the technique of centralize exception handling without try catch
blocks in c#.

 

[Guest]

In your startup method:
Application.ThreadException += new
System.Threading.ThreadExceptionEventHandler(eh.OnThreadException);
Application.Run(new frmMain());

where eh is an instance of the class that will handle the 'unexpected
exceptions'.

internal void OnThreadException(object sender,
System.Threading.ThreadExceptionEventArgs t)
{
Exception e = t.Exception;
StackTrace st = new StackTrace(e);
.... retrieve the method stack for diagnostic purposes
... display a friendly message, etc.
}

David Anton
www.tangiblesoftwaresolutions.com
Home of the Instant C# VB.NET to C# converter
and the Instant VB C# to VB.NET converter

 

[Guest]

There's also another event that is fired from the current AppDomain called
UnhandledException - I recommend assigning a delegate to both the Thread and
the AppDomain exception events to limit the chance of the exception not
getting handled.

AppDomain.CurrentDomain.UnhandledException += new
UnhandledExceptionEventHandler(eh.UnhandledExceptionHandler);

Application.ThreadException += new
System.Threading.ThreadExceptionEventHandler(eh.OnThreadException);

 

[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???

After reading your's reply i use both Application.ThreadException and
AppDomain.CurrentDomain.UnhandledException event in order to capture all
types of exception both within IDE and outside the IDE.

Now please guide me whether it is good technique for central exception
handling or i need two startup classes to handle Exception.One for handling
Exception Within the IDE or 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

 

[Guest]

I think having one exception handling class for running inside and outside
the IDE is appropriate and your sample code looks okay to me.

 

[David Levine]

There are several potential problems you should be aware of.

First, in the current shipping version of the runtime (v1.1), even though
you can successfully subscribe to the AppDomain.UnhandledException, the
event only gets delivered to handlers that reside in the default appdomaion.
If your code runs in a different appdomain it will never get the event, and
you will never even know that it wont get delivered. This is also true of
several other system notifications, such as the ProcessExit event.

Second, using a UE handler does not really handle the exception, it just
provides a last ditch place for you to get notified that a problem occurred.
It does not allow you to recover from it (except only in the most general
way).

Third, even though UEs are only fatal if it occurs on the main thread of
your application, this will not be true in future releases of the runtime.
This is a policy decision of the application and it will probably change so
that all UEs are fatal unless the runtime is otherwise instructed.

In general I disagree with the notion that it's ok to ingnore error handling
(re: try-catch) on all threads except the main thread because a global piece
of code somewhere else will handle it all for you.

 

[Guest]

Everyone has a right to their own opinion, but I would add that in general
using a global error handler in combination with selective use of try/catch
works out well enough for most situations.

Insisting on the use of try/catch in every method of every class is just way
too anal retentive.

 

[David Levine]

As you say, it's your opinion and you are entitled to it.

I've never said that every method in every class should have a try-catch -
that would actually be bad, not good....but every thread ought to have one
at the top of the thread, and every place where an exception could be
dropped (e.g. threadpool callback routines) ought to have one. If you choose
not to do that, well, my caring too much about someone else's code really
would be anal retentive.

Everyone has a right to their own opinion, but I would add that in general
using a global error handler in combination with selective use of
try/catch
works out well enough for most situations.

Insisting on the use of try/catch in every method of every class is just
way
too anal retentive.

--
Jorge L. Matos

There are several potential problems you should be aware of.

First, in the current shipping version of the runtime (v1.1), even though
you can successfully subscribe to the AppDomain.UnhandledException, the
event only gets delivered to handlers that reside in the default
appdomaion.
If your code runs in a different appdomain it will never get the event,
and
you will never even know that it wont get delivered. This is also true of
several other system notifications, such as the ProcessExit event.

Second, using a UE handler does not really handle the exception, it just
provides a last ditch place for you to get notified that a problem
occurred.
It does not allow you to recover from it (except only in the most general
way).

Third, even though UEs are only fatal if it occurs on the main thread of
your application, this will not be true in future releases of the
runtime.
This is a policy decision of the application and it will probably change
so
that all UEs are fatal unless the runtime is otherwise instructed.

In general I disagree with the notion that it's ok to ingnore error
handling
(re: try-catch) on all threads except the main thread because a global
piece
of code somewhere else will handle it all for you.

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

After reading your's reply i use both Application.ThreadException and
AppDomain.CurrentDomain.UnhandledException event in order to capture
all
types of exception both within IDE and outside the IDE.

Now please guide me whether it is good technique for central exception
handling or i need two startup classes to handle Exception.One for
handling Exception Within the IDE or 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

"Jorge L Matos [MCSD.NET]" <matos_jorge_NOSPAM_AT_hotmail.com> wrote in
message There's also another event that is fired from the current AppDomain
called
UnhandledException - I recommend assigning a delegate to both the
Thread
and
the AppDomain exception events to limit the chance of the exception
not
getting handled.

AppDomain.CurrentDomain.UnhandledException += new
UnhandledExceptionEventHandler(eh.UnhandledExceptionHandler);

Application.ThreadException += new
System.Threading.ThreadExceptionEventHandler(eh.OnThreadException);


:

In your startup method:
Application.ThreadException += new
System.Threading.ThreadExceptionEventHandler(eh.OnThreadException);
Application.Run(new frmMain());

where eh is an instance of the class that will handle the 'unexpected
exceptions'.

internal void OnThreadException(object sender,
System.Threading.ThreadExceptionEventArgs t)
{
Exception e = t.Exception;
StackTrace st = new StackTrace(e);
.... retrieve the method stack for diagnostic purposes
... display a friendly message, etc.
}

David Anton
www.tangiblesoftwaresolutions.com
Home of the Instant C# VB.NET to C# converter
and the Instant VB C# to VB.NET converter

:

please tell the technique of centralize exception handling without
try
catch
blocks in c#.