Trapping Exceptions - another issue

I'm trying to capture all unhandled exceptions in my Forms Application.
First I subscribe to ThreadException ...
public Form1()
{
InitializeComponent();
Application.ThreadException += new
System.Threading.ThreadExceptionEventHandler(Application_ThreadException);

Then I define a method to handle the event....

private static void CurrentDomain_UnhandledException(object sender,
UnhandledExceptionEventArgs ue)
{
Exception myEx = (Exception)ue.ExceptionObject;
here I write to the database logging exception details - the data gets
written ok

To force an exception I put a button on my form and I handle the click as
....

private void btnBlow_Click(object sender, EventArgs e)
{
decimal dec = Convert.ToDecimal("MakeException"); //cause an
exception
}

The intentional exception triggers my method just fine. But then the
btnBlow_click gets triggered again - over and over forever. I don't know why
that is happening.

thanks,
Gary

v-lliu
Fri Apr 27 05:13:29 CDT 2007

Hi Gary,

Firstly, I'd like to say that the behaviors of the exception handling are
different when an application is run with and without VS debugger. When an
application is run with VS debugger, VS debugger will catch and handle the
exception as well. I suggest that you double-click the application to run
it directly to test the exception handling in your application.

In WinForm applications, exceptions occurring in the main thread are caught
and handled by CLR(a default exception dialog will be shown) and this
doesn't terminate the application, although the application is left in an
unknown state. We could hook up and handle the Application.ThreadException
event to provide a custom exception dialog.

If the exception occurs in a thread other than the main thread, the
Application.ThreadException event won't be raised. In this case, we could
subscribe the AppDomain.UnhandledException event to handle the exceptions
that the Application.ThreadException event hanlder can't catch.

The AppDomain.UnhandledException event provides notification of uncaught
exceptions. It allows the application to log information about the
exception before the system default handler reports the exception to the
user and terminates the application.

In addition, if we use the Application.SetUnhandledExceptionMode method to
change the mode to UnhandledExceptionMode.ThrowException before the
Application.ThreadException event handler is hooked up, exceptions
occurring in the main thread won't be routed to the ThreadException
handler, instead, the AppDomain.UnhandledException event handler is called.

For a complete sample about handling exception, you may visit the following
link:
http://msdn2.microsoft.com/en-us/library/system.windows.forms.unhandledexcep
tionmode.aspx

Hope this helps.
If you have any question, please feel free to let me know.

Sincerely,
Linda Liu
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

GaryDean
Fri Apr 27 10:45:56 CDT 2007

I don't see any samples at that link. It just briefly describes the issue.
I have never been able to see any samples in C# of this that work.
Gary

"Linda Liu [MSFT]" <v-lliu@online.microsoft.com> wrote in message
news:2Qev6SLiHHA.2164@TK2MSFTNGHUB02.phx.gbl...
> Hi Gary,
>
> Firstly, I'd like to say that the behaviors of the exception handling are
> different when an application is run with and without VS debugger. When an
> application is run with VS debugger, VS debugger will catch and handle the
> exception as well. I suggest that you double-click the application to run
> it directly to test the exception handling in your application.
>
> In WinForm applications, exceptions occurring in the main thread are
> caught
> and handled by CLR(a default exception dialog will be shown) and this
> doesn't terminate the application, although the application is left in an
> unknown state. We could hook up and handle the Application.ThreadException
> event to provide a custom exception dialog.
>
> If the exception occurs in a thread other than the main thread, the
> Application.ThreadException event won't be raised. In this case, we could
> subscribe the AppDomain.UnhandledException event to handle the exceptions
> that the Application.ThreadException event hanlder can't catch.
>
> The AppDomain.UnhandledException event provides notification of uncaught
> exceptions. It allows the application to log information about the
> exception before the system default handler reports the exception to the
> user and terminates the application.
>
> In addition, if we use the Application.SetUnhandledExceptionMode method to
> change the mode to UnhandledExceptionMode.ThrowException before the
> Application.ThreadException event handler is hooked up, exceptions
> occurring in the main thread won't be routed to the ThreadException
> handler, instead, the AppDomain.UnhandledException event handler is
> called.
>
> For a complete sample about handling exception, you may visit the
> following
> link:
> http://msdn2.microsoft.com/en-us/library/system.windows.forms.unhandledexcep
> tionmode.aspx
>
> Hope this helps.
> If you have any question, please feel free to let me know.
>
> Sincerely,
> Linda Liu
> Microsoft Online Community Support
>
> ==================================================
> Get notification to my posts through email? Please refer to
> http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
> ications.
>
> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> where an initial response from the community or a Microsoft Support
> Engineer within 1 business day is acceptable. Please note that each follow
> up response may take approximately 2 business days as the support
> professional working with you may need further investigation to reach the
> most efficient resolution. The offering is not appropriate for situations
> that require urgent, real-time or phone-based interactions or complex
> project analysis and dump analysis issues. Issues of this nature are best
> handled working with a dedicated Microsoft Support Engineer by contacting
> Microsoft Customer Support Services (CSS) at
> http://msdn.microsoft.com/subscriptions/support/default.aspx.
> ==================================================
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>

GaryDean
Fri Apr 27 11:03:55 CDT 2007

Linda:
By the way, don't worry about finding an example as I have it working now
with both ThreadExceptionEventHandler and UnhandledExceptionEventHandler.

Thanks so much for you help.

--
Regards,
Gary Blakely
"Linda Liu [MSFT]" <v-lliu@online.microsoft.com> wrote in message
news:2Qev6SLiHHA.2164@TK2MSFTNGHUB02.phx.gbl...
> Hi Gary,
>
> Firstly, I'd like to say that the behaviors of the exception handling are
> different when an application is run with and without VS debugger. When an
> application is run with VS debugger, VS debugger will catch and handle the
> exception as well. I suggest that you double-click the application to run
> it directly to test the exception handling in your application.
>
> In WinForm applications, exceptions occurring in the main thread are
> caught
> and handled by CLR(a default exception dialog will be shown) and this
> doesn't terminate the application, although the application is left in an
> unknown state. We could hook up and handle the Application.ThreadException
> event to provide a custom exception dialog.
>
> If the exception occurs in a thread other than the main thread, the
> Application.ThreadException event won't be raised. In this case, we could
> subscribe the AppDomain.UnhandledException event to handle the exceptions
> that the Application.ThreadException event hanlder can't catch.
>
> The AppDomain.UnhandledException event provides notification of uncaught
> exceptions. It allows the application to log information about the
> exception before the system default handler reports the exception to the
> user and terminates the application.
>
> In addition, if we use the Application.SetUnhandledExceptionMode method to
> change the mode to UnhandledExceptionMode.ThrowException before the
> Application.ThreadException event handler is hooked up, exceptions
> occurring in the main thread won't be routed to the ThreadException
> handler, instead, the AppDomain.UnhandledException event handler is
> called.
>
> For a complete sample about handling exception, you may visit the
> following
> link:
> http://msdn2.microsoft.com/en-us/library/system.windows.forms.unhandledexcep
> tionmode.aspx
>
> Hope this helps.
> If you have any question, please feel free to let me know.
>
> Sincerely,
> Linda Liu
> Microsoft Online Community Support
>
> ==================================================
> Get notification to my posts through email? Please refer to
> http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
> ications.
>
> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> where an initial response from the community or a Microsoft Support
> Engineer within 1 business day is acceptable. Please note that each follow
> up response may take approximately 2 business days as the support
> professional working with you may need further investigation to reach the
> most efficient resolution. The offering is not appropriate for situations
> that require urgent, real-time or phone-based interactions or complex
> project analysis and dump analysis issues. Issues of this nature are best
> handled working with a dedicated Microsoft Support Engineer by contacting
> Microsoft Customer Support Services (CSS) at
> http://msdn.microsoft.com/subscriptions/support/default.aspx.
> ==================================================
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>