Bug in the Framework? Please, read it.

  • Thread starter Thread starter Mayerber
  • Start date Start date
M

Mayerber

Hi,

I'm having a problem with Exceptions inside Drag&Drop
events. Here are the steps to reproduce the situation:

1) Create a new C# Windows Application;
2) Set Form1's AllowDrop property to True;
3) Type the following inside the form's DoubleClick event:
string[] a = new string[2];
a[500] = "ae";
4) Type the same inside the form's DragEnter event:
string[] a = new string[2];
a[500] = "ae";

The final code should look like:
private void Form1_DoubleClick(object sender,
System.EventArgs e)
{
string[] a = new string[2];
a[500] = "ae";
}

private void Form1_DragEnter(object sender,
System.Windows.Forms.DragEventArgs e)
{
string[] a = new string[2];
a[500] = "ae";
}

Now, run the application by pressing F5. Double-click the
Form and hopefully the "An unhandled exception of type
System.IndexOutOfRangeException..." message will be shown.
That's alright since we are accessing the 500th position
of the array and it only has 2. But now, instead of double-
clicking, drag a file onto the form. Where's the exception
message?! It is never shown!

I tried this on 3 different computers running Windows XP
SP1 (on 2 of them) and Windows 2000 Professional (on the
third) and I always get this weird behavior. Also, I
noticed this is happening inside any Drag&Drop event
(DragEnter, DragDrop, etc.)

Any comments?

All of the code was tested using MS Visual Studio .NET
2003 with .NET Framework v1.1.

Best regards,
mayerber.
 
1) Create a new C# Windows Application;
2) Set Form1's AllowDrop property to True;
3) Type the following inside the form's DoubleClick event:
string[] a = new string[2];
a[500] = "ae";
4) Type the same inside the form's DragEnter event:
string[] a = new string[2];
a[500] = "ae";
Click to expand...

I can reproduce the behavior. I also find it very odd.
Let's hope someone from MS will also confirm this.

Regards, Wiktor
 
Mayerber said:
Hi,

I'm having a problem with Exceptions inside Drag&Drop
events. Here are the steps to reproduce the situation:

1) Create a new C# Windows Application;
2) Set Form1's AllowDrop property to True;
3) Type the following inside the form's DoubleClick event:
string[] a = new string[2];
a[500] = "ae";
4) Type the same inside the form's DragEnter event:
string[] a = new string[2];
a[500] = "ae";

The final code should look like:
private void Form1_DoubleClick(object sender,
System.EventArgs e)
{
string[] a = new string[2];
a[500] = "ae";
}

private void Form1_DragEnter(object sender,
System.Windows.Forms.DragEventArgs e)
{
string[] a = new string[2];
a[500] = "ae";
}

Now, run the application by pressing F5. Double-click the
Form and hopefully the "An unhandled exception of type
System.IndexOutOfRangeException..." message will be shown.
That's alright since we are accessing the 500th position
of the array and it only has 2. But now, instead of double-
clicking, drag a file onto the form. Where's the exception
message?! It is never shown!

I tried this on 3 different computers running Windows XP
SP1 (on 2 of them) and Windows 2000 Professional (on the
third) and I always get this weird behavior. Also, I
noticed this is happening inside any Drag&Drop event
(DragEnter, DragDrop, etc.)

Any comments?
Click to expand...

Apparently the System.Windows.Forms.Control class is setting up a
try..catch block around the DragEnter events and handling the exception.
The exception is being thrown - you can verify this by putting the
'a[500] = "ae";' statement inside your own try...catch.

Whether or not this is a bug... I think most would classify it as an
undocumented but valid behavior of the framework.
 
Hi,

I don't think the Forms.Control is handling the exception
all by itself. What if the exception thrown is a user-
defined one that should be propagated back on the call
stack to an user-defined exception handler?

Still, if the Forms.Control class in fact catches the
exception, why is it not telling the programmer about the
existance of the exception? How can I fix my code if I
don't even know that there's an exception being raised in
the first place?

Whether it is a "valid behavior" of the Framework, I have
my doubts. I don't think that hiding the report of an
unhandled exception makes up for a valid behavior.
 
Mayerber said:
Hi,

I don't think the Forms.Control is handling the exception
all by itself.
Click to expand...

The exception is getting thrown, so something's catching it.
What if the exception thrown is a user-
defined one that should be propagated back on the call
stack to an user-defined exception handler?
Click to expand...

There's not much of a call stack here that is user code - it's the
framework's call stack firing the event. You can override
OnDragEnter(), in which case your implementation of OnDragEnter() is on
the call stack, and can catch the exception.

If you have some sort of application-wide exception handler, then this
exception is probably masked from it, and you might have to convince MS
that this is a bug that needs fixing.
Still, if the Forms.Control class in fact catches the
exception, why is it not telling the programmer about the
existance of the exception? How can I fix my code if I
don't even know that there's an exception being raised in
the first place?

Whether it is a "valid behavior" of the Framework, I have
my doubts. I don't think that hiding the report of an
unhandled exception makes up for a valid behavior.
Click to expand...

I'd bet that there are many places that the Framework code catches
exceptions that might possibly mask errors. Having unhandled exceptions
pop-up during testing is a good way to find bugs, but I'm not sure that
they are intended to be a catch-all.

To be clear I'm not insisting that this isn't a Framework bug.

By the way, I'm testing on Framework 1.0 - it's possible that 1.1 has
different behavior (if that's not what you're running on).
--
mayerber.

-----Original Message-----
Apparently the System.Windows.Forms.Control class is
Click to expand...

setting up a
try..catch block around the DragEnter events and handling
Click to expand...

the exception.
The exception is being thrown - you can verify this by
Click to expand...

putting the
'a[500] = "ae";' statement inside your own try...catch.

Whether or not this is a bug... I think most would
Click to expand...

classify it as an
Click to expand...
 
Back
Top