Exception Handling + Winforms

  • Thread starter Thread starter Ori
  • Start date Start date
O

Ori

Hi,

I would like to create some mechanism to handle all the exceptions
which will happen in my application.

I have one form which is the base form while all the other forms
inherit from it.

I try to find a way to "register" the base form to the Error handling
, but I don't know how….

Basically I'm try to catch an exceptions which occur in form2 (which
inherit from form1) through and exception handling which I will
implement through form1.

If any one has any idea, please let me know.

Thanks,

Ori.
 
Ori,
Depending on the type of application you are creating, .NET has three
different global exception handlers.

For ASP.NET look at:
System.Web.HttpApplication.Error event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomain.UnhandledException event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows.Forms.Application.ThreadException event
Use AddHandler in your Sub Main.

Hope this helps
Jay
 
Check out the Application.ThreadException
http://tinyurl.com/2upm9

Remarks
This event allows your Windows Forms application to handle otherwise
unhandled exceptions. Attach your event handlers to the ThreadException
event to deal with these exceptions, as these exceptions will leave your
application in an unknown state. Where possible, exceptions should be
handled by a structured exception handling block.
 
Hello Jay,
For console applications look at:
System.AppDomain.UnhandledException event
Use AddHandler in your Sub Main.

Is this event only for console applications? I thought it is raised despite
the type of the application (well, ASP .NET ones can be an exception). The
docs seem to say nothing about WinForms or console applications in the
"AppDomain.UnhandledException" topic.

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://x-unity.miik.com.ua/teststudio.aspx
Bring the power of unit testing to VS .NET IDE
 
Dmitriy,
Yes its raised on all three, however it is the only one raised for console
applications, the other two are not.

My understanding of the event itself, which I admit is limited, its
usefulness in ASP.NET & Windows Form is "limited", hence my statement "for
console application". As I personally do not have a clear indication of when
you would need to include it in ASP.NET & Windows Forms, at least I cannot
really explain it. If you have something the clearly & briefly explains when
the event is raised, I would love to hear it.

Remember most unhandled exceptions in most Windows Forms apps will be
handled by the Application.ThreadException, the AppDomain.UnhandledException
will only handle the exceptions not handled by the above handler... (at
least that is my experience).

Hope this helps
Jay

Dmitriy Lapshin said:
Hello Jay,
For console applications look at:
System.AppDomain.UnhandledException event
Use AddHandler in your Sub Main.

Is this event only for console applications? I thought it is raised despite
the type of the application (well, ASP .NET ones can be an exception). The
docs seem to say nothing about WinForms or console applications in the
"AppDomain.UnhandledException" topic.

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://x-unity.miik.com.ua/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

Jay B. Harlow said:
Ori,
Depending on the type of application you are creating, .NET has three
different global exception handlers.

For ASP.NET look at:
System.Web.HttpApplication.Error event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomain.UnhandledException event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows.Forms.Application.ThreadException event
Use AddHandler in your Sub Main.

Hope this helps
Jay
 
Remember most unhandled exceptions in most Windows Forms apps will be
handled by the Application.ThreadException, the AppDomain.UnhandledException
will only handle the exceptions not handled by the above handler... (at
least that is my experience).

Yes, I have bumped into something similar when working on a VS .NET add-in.
Strangely enough, the UnhandledException event didn't raise for the primary
thread the add-in was running on, while the event was raised as expected for
any other thread I had created manually. This came as a big and unpleasant
surprise, and I still haven't got any 'official' explanation. My only guess
is since VS .NET communicates with the add-in through CCW (COM-callable
wrappers), it is possible the framework silently installs its own handler
for the UnhandledException event to translate a managed exception to a COM
error (HRESULT + IErrorInfo).

As for the WinForms and ASP .NET applications, it is indeed better to use
the recommended means such as Application.ThreadException. Still, I'd add a
handler for UnhandledException too not to miss "survivors" who managed to
bypass the "first line of defense".

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://x-unity.miik.com.ua/teststudio.aspx
Bring the power of unit testing to VS .NET IDE
 
Dmitriy,
Still, I'd add a
handler for UnhandledException too not to miss "survivors" who managed to
bypass the "first line of defense".
You won't get an argument for me, I was attempting the highlight just the
first line of defense, in an effort to "keep it simple".

When I use my exception snippet again I will try to incorporate our
discussion...

Thanks
Jay

Dmitriy Lapshin said:
Remember most unhandled exceptions in most Windows Forms apps will be
handled by the Application.ThreadException, the AppDomain.UnhandledException
will only handle the exceptions not handled by the above handler... (at
least that is my experience).

Yes, I have bumped into something similar when working on a VS .NET add-in.
Strangely enough, the UnhandledException event didn't raise for the primary
thread the add-in was running on, while the event was raised as expected for
any other thread I had created manually. This came as a big and unpleasant
surprise, and I still haven't got any 'official' explanation. My only guess
is since VS .NET communicates with the add-in through CCW (COM-callable
wrappers), it is possible the framework silently installs its own handler
for the UnhandledException event to translate a managed exception to a COM
error (HRESULT + IErrorInfo).

As for the WinForms and ASP .NET applications, it is indeed better to use
the recommended means such as Application.ThreadException. Still, I'd add a
handler for UnhandledException too not to miss "survivors" who managed to
bypass the "first line of defense".

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://x-unity.miik.com.ua/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

Jay B. Harlow said:
Dmitriy,
Yes its raised on all three, however it is the only one raised for console
applications, the other two are not.

My understanding of the event itself, which I admit is limited, its
usefulness in ASP.NET & Windows Form is "limited", hence my statement "for
console application". As I personally do not have a clear indication of when
you would need to include it in ASP.NET & Windows Forms, at least I cannot
really explain it. If you have something the clearly & briefly explains when
the event is raised, I would love to hear it.

Remember most unhandled exceptions in most Windows Forms apps will be
handled by the Application.ThreadException, the AppDomain.UnhandledException
will only handle the exceptions not handled by the above handler... (at
least that is my experience).

Hope this helps
Jay
 
Jay,

I didn't mean to argue either, my sole intention was to warn you and the
community that peculiar things with UnhandledException could happen and they
were undocumented.

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://x-unity.miik.com.ua/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

Jay B. Harlow said:
Dmitriy,
Still, I'd add a
handler for UnhandledException too not to miss "survivors" who managed to
bypass the "first line of defense".
You won't get an argument for me, I was attempting the highlight just the
first line of defense, in an effort to "keep it simple".

When I use my exception snippet again I will try to incorporate our
discussion...

Thanks
Jay

Dmitriy Lapshin said:
Yes, I have bumped into something similar when working on a VS .NET add-in.
Strangely enough, the UnhandledException event didn't raise for the primary
thread the add-in was running on, while the event was raised as expected for
any other thread I had created manually. This came as a big and unpleasant
surprise, and I still haven't got any 'official' explanation. My only guess
is since VS .NET communicates with the add-in through CCW (COM-callable
wrappers), it is possible the framework silently installs its own handler
for the UnhandledException event to translate a managed exception to a COM
error (HRESULT + IErrorInfo).

As for the WinForms and ASP .NET applications, it is indeed better to use
the recommended means such as Application.ThreadException. Still, I'd
add
a
handler for UnhandledException too not to miss "survivors" who managed to
bypass the "first line of defense".

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://x-unity.miik.com.ua/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

Dmitriy,
Yes its raised on all three, however it is the only one raised for console
applications, the other two are not.

My understanding of the event itself, which I admit is limited, its
usefulness in ASP.NET & Windows Form is "limited", hence my statement "for
console application". As I personally do not have a clear indication
of
when
you would need to include it in ASP.NET & Windows Forms, at least I cannot
really explain it. If you have something the clearly & briefly
explains
when
the event is raised, I would love to hear it.

Remember most unhandled exceptions in most Windows Forms apps will be
handled by the Application.ThreadException, the AppDomain.UnhandledException
will only handle the exceptions not handled by the above handler... (at
least that is my experience).

Hope this helps
Jay
 
Back
Top