Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Windows Forms / WinForm General / February 2005

Tip: Looking for answers? Try searching our database.

Strange exception behaviour

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Jos Beelen - 10 Feb 2005 19:55 GMT
Examine the following code fragment used from within the
main form of a windows forms application when clicking a
button:

private void button1_Click(object s, System.EventArgs e)
{
try
{
  Form2 f2 = new Form2();
  f2.ShowDialog();
}
catch (Exception ex)
{
  MessageBox.Show ("Error catched");
}
}

Form2 also contains a button and when the button is
clicked, a divide by zero exception is created by the
following code:

private void button2_Click(object s, System.EventArgs e)
{
 int i,j;
 i = 0;
 j = 1/i;  // Divide by zero
}

Because the exception is not catched in Form2, I expect
this exception is catched by the code fragment in the main
form by displaying the message "Error catched", but the
behaviour is very strange.

1. When running the application from within VS2003 using
F5 (=debug), the error is catched, so my messagebox is
displayed. This is the same for both running in release
mode and debug mode. This is the expected behaviour !!!!

2. When running the application from wihtin VS2003 using
ctrl-F5 (=no debug), the standard "unhandled exception"
window is displayed. This is the same for both running in
release mode and debug mode. This behaviour is also the
same when running the application outside the studio (=
the behaviour when the application is deployed).

Question:
Why is the exception in -2- not catched by the implemented
catch. I expected the same behaviour as in -1-

I know I can use Application.ThreadException to catch the
unhandled exception, but this is not the requested
functionality. I want the calling method to handle the
exception.

Who can help me ....

Thanks in advance.
Matt Garven - 10 Feb 2005 23:53 GMT
Hi Jos,

The difference in behaviour that you're seeing comes from the NativeWindow
class where it assigns a different Callback delegate based on whether or not
a debugger is attached. The DebuggableCallback delegate has no try/catch
block so the exception "bubbles up" to your handler, whereas the Callback
delegate has a try/catch block and in the catch passes the exception directly
to the OnThreadException handler.

If you want to prevent this from occurring in an application, you need to
add a handler to the Application.ThreadException event (and you should also
add a handler to AppDomain.UnhandledException).

Hope this helps.

Regards,
Matt Garven

> Examine the following code fragment used from within the
> main form of a windows forms application when clicking a
[quoted text clipped - 53 lines]
>
> Thanks in advance.
Jos Beelen - 11 Feb 2005 08:10 GMT
Matt, thank you for your quick response.

I do understand the difference now, but when no debugger
is attached, I expect a "normal" behaviour.

According to the documentation (.NET Framework developers
guide, Exceptions Overview c#), the runtime should search
the stack for a caller who handles the exception. When no
match is found, the exception is treated as unhandled.

So when an exceptions occurs somewhere, it bubbles up
until a catch is found which is able to handle the
exception. In my example the first catch found should be
in the button1_Click method. So I expect my messagebox is
displayed in this case.

Instead of displaying my messagebox, the run-time handles
it as an unhandled exception. But it is handled, it is
within a try - catch block !!!

Is this "as designed", a bug or do I miss something ???

Jos

>-----Original Message-----
>Hi Jos,
[quoted text clipped - 74 lines]
>>
>.
Bruce Wood - 11 Feb 2005 17:22 GMT
I think that Matt is describing an effect that I have also seen when
invoking just-in-time debugging: an exception occurs in an event
handler, but the JIT debugger can't tell me where: all it can tell me
is that it happened somewhere inside a .ShowDialog() invocation. So,
I'm left sitting with the debugger pointing to the .ShowDialog() call,
and showing an exception that obviously happened in some event handler
deep inside the form I called.

As Matt said, this has to do with how .NET is handling calls to the
native windowing API. Somehow it plays some trickery with the stack at
run time so that your event handler kinda-isn't-on-the-stack when the
exception occurs, or is in a different thread or something. I'm a bit
foggy on it myself.
Matt Garven - 12 Feb 2005 04:55 GMT
It is as designed, but it's nothing particularly magical - it's just a bit
obscure.

Your try/catch sits lower than the try/catch in the Callback method of
NativeWindow, so it is the Callback method which handles the exception first.
It passes the exception directly to the OnThreadException handler and then
you see the "unhandled exception" dialog.

However, when your debugger is attached (regardless of release mode or debug
mode), NativeWindow uses the DebuggableCallback method instead of the
Callback method. This does not have the try/catch block so the exception is
free to bubble up the stack and therefore gets caught by your try/catch block.

Why? You'll notice that when the debugger is attached the form closes after
the exception occurs (ie it dies horribly). However, when the debugger isn't
attached, the form stays on the screen (ie doesn't die). Perhaps this was
intended as a way to add extra stability to WinForms apps so they don't fall
over every time an exception occurs.

Hope this helps.

Regards,
Matt Garven

> Matt, thank you for your quick response.
>
[quoted text clipped - 122 lines]
> >>
> >.

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.