ListView.Items.Add exception causing pause

S

snarfblam

Ultimate Contributor
Joined
Jun 10, 2003
Messages
2,097
Location
USA
I am making an app that uses a listview. I add ListViewItems to the ListView.Items collection using ListView.Items.Add. Every time I add an item, an exception is thrown and handled within System.Windows.Forms.dll. This is not breaking my application, however it causes a pause when the first exception is thrown.

Is this normal behavior? Or some sort of bug? I am not changing any properties after I instantiate the listview items, so I'm nearly positive that I'm not doing anything wrong. I'm sure that Microsoft does not condone using exceptions as a form of program flow control, however this happens every time I add an item not only causing the pause, but making it nearly impossible to debug when the debugger is set to break on all exceptions.
 
IngisKahn said:
Which begs the question: What execption is being thrown?
Click to expand...

Whoops. Certianly a fair question.

A first chance exception of type 'System.ArgumentOutOfRangeException'
occurred in system.windows.forms.dll

Additional information: Specified argument was out of the range of valid
values.

I have noticed this behavior before, with the pausing and exceptions and whatnot. Since both the throwing and handling of the exception is happening in the System.Windows.Forms.dll I can't get the details. For the same reason, I have ignored the error in the past, but the pausing is getting on my nerves and I would really like the debugger to break on all exceptions, but when I add 20 items to the listview it is very annoying to break into the debugger 20 times.
 
Just in case anyone else runs into this problem:

After a few hours of trying to solve this issue, I figured this out tonight. Although I discovered that this exception will only occur when visual styles are enabled, this exception does not occur at all when I do something that I should have been doing in the first place. Calling ListView.BeginUpdate() before modifying the ListViewItemCollection, and calling ListView.EndUpdate() after modifying the collection prevents this exception from being raised.
 
marble_eater said:
This is not breaking my application, however it causes a pause when the first exception is thrown.
Is this normal behavior? Or some sort of bug?
Click to expand...

Some exceptions require a lot of setup which is only jitted and executed when the exception is needed, which is sensible. When you throw the exception a stacktrace will be created which is a tricky job and requires that the stack hierarchy not be changing underneath it, that means it can be slow. When the exception if formed the runtime has to walk the stack looking for active exception handlers and determining if they apply to the particular exception it is throwing, again this can be understandably slow. Certain types of exception (COMException and Win32Exception) may also require pinvoke marshalling and incur even more time penalty on use.

In the case of windows forms i find it not unusual to have a stack depth of 20+ methods even on the simplest events. Windows forms is a complex wrapper around the native windows implementation and its big in both depth and breadth.

Exceptions are slow, avoid where humanly possible.
 
Wraith said:
Exceptions are slow, avoid where humanly possible.
Click to expand...
That is why this topic exists. I know all about exceptions. After the first exception is thrown in an application, however, you would be surprised to see just how quickly exceptions are handled. In my application, after the initial exception, the speed difference caused by exceptions (generally 10-50) was negligible. People have posted (I don't know if this was on this board) that in their applications, even significantly greater numbers of exceptions still have minimal impact in performance.

Of course this is not to say that exceptions should occur commonly or be used as a program flow mechanism. Any programmer should be aware that exceptions are intended only for exceptional circumstances, hence the name.
 
Back
Top