UserControl - Exceptions

[Jeff]

I'm just starting to work with UserControls and have a question on the
behavoir of exceptions within UserControls and VS.Net 2003.

I have noticed that when a UserControl throws an exception from an event
(i.e. Click event), VS.Net will enter debug mode on the exact line that
threw the exception in the UserControl. You can see the complete call stack
up to the Click event, all local variables from the Click event, etc.
However, if an exception is thrown from the Paint event, VS.Net will enter
debug mode on the line following Application.Run(new Form1()); in the parent
form. The only information in the call stack is the Main() method and you
have no clue as to what line of code threw the exception nor access to local
variable from the Paint event.

Obviously the information from an exception in the Click event is much more
useful than the information from an exception in the Paint event.

Here is how to reproduce this behavior:

1. Create a new C# windows application called ExceptionTest
2. Create a new UserControl called ExceptionControl1
3. Add an event handler for the Click event and Paint event
4. Add the following line of code to the click event:
throw new OverflowException();
5. Build the project
6. Add the ExceptionControl1 to Form1
7. Run the project
8. When you click the area where you placed the ExceptionControl1 an
exception will be thrown and the VS.net debugger should take you right to
the Click event code.
9. Stop debugging and move the one line of code from the Click event to the
Paint event.
10. Run the project
11. The application should throw an exception immediatley and the VS.Net
debugger should dump you in the Form1.Main() method. Pretty useless.

My question is, why is there a difference and how can I use VS.Net to begin
debugging within the Paint method when an exception is thrown?

 

[Kevin Yu [MSFT]]

Hi Jeff.

We have reviewed this issue and are currently researching on it. We will
update you ASAP. Thanks for your patience!

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

 

[David Levine]

I'm just starting to work with UserControls and have a question on the
behavoir of exceptions within UserControls and VS.Net 2003.

I have noticed that when a UserControl throws an exception from an event
(i.e. Click event), VS.Net will enter debug mode on the exact line that
threw the exception in the UserControl. You can see the complete call stack
up to the Click event, all local variables from the Click event, etc.
However, if an exception is thrown from the Paint event, VS.Net will enter
debug mode on the line following Application.Run(new Form1()); in the parent
form. The only information in the call stack is the Main() method and you
have no clue as to what line of code threw the exception nor access to local
variable from the Paint event.

Obviously the information from an exception in the Click event is much more
useful than the information from an exception in the Paint event.

Here is how to reproduce this behavior:

1. Create a new C# windows application called ExceptionTest
2. Create a new UserControl called ExceptionControl1
3. Add an event handler for the Click event and Paint event
4. Add the following line of code to the click event:
throw new OverflowException();
5. Build the project
6. Add the ExceptionControl1 to Form1
7. Run the project
8. When you click the area where you placed the ExceptionControl1 an
exception will be thrown and the VS.net debugger should take you right to
the Click event code.
9. Stop debugging and move the one line of code from the Click event to the
Paint event.
10. Run the project
11. The application should throw an exception immediatley and the VS.Net
debugger should dump you in the Form1.Main() method. Pretty useless.

My question is, why is there a difference and how can I use VS.Net to begin
debugging within the Paint method when an exception is thrown?

Probably because the winform library wraps the call to the paint event in
its own try-catch handler, perhaps at the level of the wndproc itself.

You should be able to have the debugger pop up on the line that throws the
exception by setting it to break on 1st chance exceptions. To do this, go
into VS 2003 and go to menu "Debug\Exceptions". A dialog will open with a
treeview control in it. Highlite the node titled "Common Language Runtime
Exceptions". At the bottom are 2 radio controls. Set the top to the line
that says "Break into the debugger" and select OK.

The debugger should now break on the line in the Paint routine that throws
the exception.

 

[Jeff]

Hi Jeff.

We have reviewed this issue and are currently researching on it. We will
update you ASAP. Thanks for your patience!

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

Great! Looking forward to hearing back from you!

 

[Jeff]

Probably because the winform library wraps the call to the paint event in
its own try-catch handler, perhaps at the level of the wndproc itself.

You should be able to have the debugger pop up on the line that throws the
exception by setting it to break on 1st chance exceptions. To do this, go
into VS 2003 and go to menu "Debug\Exceptions". A dialog will open with a
treeview control in it. Highlite the node titled "Common Language Runtime
Exceptions". At the bottom are 2 radio controls. Set the top to the line
that says "Break into the debugger" and select OK.

The debugger should now break on the line in the Paint routine that throws
the exception.

Thanks David, that seems to be a good workaround as the debugger will
actually stop in the Paint event now. However, it also stops on all the
other exceptions (even exceptions that are handled). Does this mean I have
to choose the lesser or two evils?

 

[David Levine]

Thanks David, that seems to be a good workaround as the debugger will
actually stop in the Paint event now. However, it also stops on all the
other exceptions (even exceptions that are handled). Does this mean I have
to choose the lesser or two evils?

yee gods, how many exceptions are you throwing? There should not be that
many! An exception should be, well, exceptional, meaning...."if this occurs
then something really really bad has happened."

I guess a more fundamental question is what are you really trying to
accomplish, and why are you using exceptions as the mechanism to get there?

 

[Kevin Yu [MSFT]]

Hi Jeff,

This is probably due to the fact that you don't have any symbols loaded for
the framework. I think the Microsoft symbols server and that should help
resolve a better callstack for you. Since an exception may be thrown in
the Paint method they are completely wrapped in GDI at this point. The
break you are seeing is the green line on the Application.Run method. This
green line indicates that the debugger stopped on the first line for which
it has symbols and source code. In order to get a break point as your
expecting you will need source code for the .NET framework.

Here's how to get symbols from the public symbol server:
http://www.microsoft.com/whdc/devtools/debugging/symbols.mspx

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

 

[Jeff]

Hi Jeff,

This is probably due to the fact that you don't have any symbols loaded
for
the framework. I think the Microsoft symbols server and that should help
resolve a better callstack for you. Since an exception may be thrown in
the Paint method they are completely wrapped in GDI at this point. The
break you are seeing is the green line on the Application.Run method.
This
green line indicates that the debugger stopped on the first line for which
it has symbols and source code. In order to get a break point as your
expecting you will need source code for the .NET framework.

Here's how to get symbols from the public symbol server:
http://www.microsoft.com/whdc/devtools/debugging/symbols.mspx

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

Does this mean I have to use WinDbg for debugging or just to download the
symbols?
Can I still use VS.Net for debugging?

 

[Jeff]

yee gods, how many exceptions are you throwing? There should not be that
many! An exception should be, well, exceptional, meaning...."if this
occurs
then something really really bad has happened."

I guess a more fundamental question is what are you really trying to
accomplish, and why are you using exceptions as the mechanism to get
there?

The problem is I'm using Managed DirectX to do some drawing routines inside
the Paint event which can throw all kinds of exceptions. I don't want to
terminate the application on some of these exceptions but rather just ignore
them because the usercontrol will be redrawn in the next Paint event (such
as surface loss because the computer went into sleep mode, etc.)

There must be a better way

 

[Kevin Yu [MSFT]]

Hi Jeff,

I think you have to use WinDbg for debugging with symbol server. Since
there is no symbol file for VS.NET, and the paint event is wrapped in GDI,
we cannot use VS.NET for debugging this.

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

 

[David Levine]

The problem is I'm using Managed DirectX to do some drawing routines inside
the Paint event which can throw all kinds of exceptions. I don't want to
terminate the application on some of these exceptions but rather just ignore
them because the usercontrol will be redrawn in the next Paint event (such
as surface loss because the computer went into sleep mode, etc.)

Just to be clear, is your code something like this...??

private void MyForm_Paint(object sender,PaintEventArgs e)
{
// calls to directX
}

If it is, then all you should need to do is wrap calls made here to DirectX
in a try-catch and you should
be able to capture all the problems right there. As in...

private void MyForm_Paint(object sender,PaintEventArgs e)
{
try
{
SomeDirectXCall();
}
catch(Exception ex)
{
// recover, report, etc.
}
}