IndexOutOfRangeException is generated by the runtime, when certain IL instructions are attempted.  ArgumentOutOfRangeException on the other hand is generated by libraries or applications which manually (from the runtime's point of view) check their parameters.

<br>

<br>Whether or not that necessitates a different exception, I'm not sure, but that's where the line is drawn.

Yeah I've always hated that.  The biggest problem is if you are coding against an IList or IList&lt;T&gt;, you might get either an ArgumentOutOfRangeException or an IndexOutOfRangeException.  I don't normally worry about this because you can catch both if you NEEDED to.  Still, like most ArgumentExceptions, these should not be caught, as they are usually programming errors.

<br>

<br>The biggest problem is if you are simply wrapping an array in your own IList implementation, you can't technically just rely on the runtime to catch an out-of-range index, as it will throw the wrong exception.  So you end up with code that double-checks the index, despite the fact that the runtime will check that index for you.

<br>

<br>For classes like ArrayList and List&lt;T&gt;, this isn't a big deal, since a check against Count has to be performed, since the array is sometimes bigger than the list.  I suppose the check against zero COULD be removed since the runtime will check it, it wouldn't exactly be clear why you aren't checking both bounds.

<br>

<br>Still, If I were designing the framework (gee, I say that a lot), I would probably have IndexOutOfRangeException derive from ArgumentOutOfRangeException, and be used for 1) indexers, and 2) any method that takes an &quot;index&quot; parameter.

You know, after thinking about this problem, I realize that it could be a lot worse.

<br>

<br>If you've ever coded against the System.Data interfaces (not a specific provider), and tried to catch exceptions, you'll see how bad it can get.

<br>

<br>If all data providers had used the same set of base classes for exceptions, this wouldn't be an issue.

<br>

<br>Catching IndexOutOfRangeException and ArgumentOutOfRangeException separately is certainly better than catching a general Exception, figuring out what happened, and rethrowing if necessary, which is often the case with System.Data.

<br>

<br>I also thought of a solution, but I highly doubt it would even be considered.

<br>

<br>Right now, Array's indexer implementation for IList is implemented as follows:

<br>

<br>object IList.this[int index]

<br>{

<br>      get

<br>      {

<br>            return this.GetValue(index);

<br>      }

<br>      set

<br>      {

<br>            this.SetValue(value, index);

<br>      }

<br>}

<br>

<br>If checks were added before the calls to GetValue and SetValue, throwing the CORRECT exception, I could certainly agree with the need for two separate exceptions.

<br>

<br>I'm not sure about IList&lt;T&gt;, which is automagically hacked into the runtime somehow.

Someone brought this to Microsoft's attention:

<br>

<br>See FDBK15779

<br>

<br><a target="_new" href="http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=7e0642a4-ce2e-455d-af3c-add4abfcc019">http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=7e0642a4-ce2e-455d-af3c-add4abfcc019</a>

<br>

<br>I'm voting for it.  Even if IList remains inconsistant, IList&lt;T&gt; doesn't need to be (they can fix this!)

Silly me.  I could have sworn I saw somebody else's name on that suggestion.  I stand corrected.

<br>

<br>The above should read:

<br>Peter brought this to Microsoft's attention.

<br>

<br>I'm going to go hide now.