SelectedIndex is SO valid!

I have run into a strange issue. Apparently, it has been around for a time. I only noticed it because I changed a setting so that my code paused when a CLR exception was thrown. Without this set, the program works fine, and I don't believe it's really an issue, but it's a bit puzzling.

I have a datatable that is set as the datasource for a listbox. This datatable starts out empty. When the user does one of a variety of things, something gets added to the datatable and it shows up in the listbox. That is what is working. However, when looking for exceptions, I found that there was an exception on this line:

mBackingStore.Tables("MWInfo").Rows.Add(ndr)

That is the line that adds a new row into the datatable. The table was empty, the table will now have one row. This causes an ArgumentOutOfRangeException with the additional infoo that 0 is not valid for SelectedIndex.

Since a datatable has no selectedindex, I assume this is refering to the listbox, but 0 IS a valid value for a listbox that has anything in it, and this one is at least ABOUT to have something in it as a result of something being added to the datatable.

So, that makes it look like the selectedindex is being advanced from -1 to 0 before the item is actually in the listbox. In other words, the act of adding to the datatable will add to the listbox, but the selectedindex of the listbox is advancing before the item is actually there.

Is that right? And secondarily, is this something that I can, or should, do anything about? Unhandled exceptions can be costly. In this case, the exception is handled internally to the CLR, because the actual behavior is correct, the item is added to the listbox and selected (I don't care that it is selected, but it is), so it works fine, there's just an unexceptional exception taking place.

Catching an exception is very costly so they should be generally avoided as a defense in lengthy loops. However, in this case it looks unavoidable. If it's causing performance problems, you might want find a way to work around it. If it is not causing noticeable performance degradation then I see no reason to worry about it. Exception handling is a really good defense against exceptional conditions that can break your code, you just can't use it haphazardly.

I tried the obvious thing: Trying to set the Selected Index to -1 preemptively, and that didn't work.

Frankly, I'm not even sure that I CAN catch this one. After all, it never stops the program, so I assume that the CLR is catching it. It's a case where the potential time cost is unimportant. The exception is thrown when the first item is added to a datatable bound to a listbox. I'm not sure that even COULD happen enough times for anybody to notice.

There's clearly nothing you can do about this but if you're interested in finding out what's actually going on, look at the stack trace of the exception to see where it's actually happening. I would imagine that it has something to do with the implementation of the ListBox - probably something in the underlying Win32 control that cannot be changed - whereby the Binding is handling an event of the DataTable and trying to set the SelectedIndex before the Items collection has actually updated. The .NET authors realised that this was happening and that they couldn't change it so they caught that exception and did whatever was appropriate to clean up.