Include actual index in IndexOutOfRange message

[danmoseley]

When testing, if you hit an IndexOutOfRangeException through out of bounds array access, it is sometimes helpful to know what the index was, to save firing up a debugger (if it will even repro).

In this context the exception is instantiated by the VM/JIT. I do not know whether this would affect performance.

 System.IndexOutOfRangeException : Index was outside the bounds of the array.
Stack Trace:
   at Microsoft.Collections.Extensions.DictionarySlim`2.Enumerator.MoveNext() in C:\git\corefxlab\src\Microsoft.Experimental.Collections\Microsoft\Collections\Extensions\DictionarySlim.cs:line 284
   at System.Linq.Enumerable.Count[TSource](IEnumerable`1 source)
   at Microsoft.Collections.Extensions.Tests.DictionarySlimTests.EnumerateCheckEnding() in C:\git\corefxlab\tests\Microsoft.Experimental.Collections.Tests\DictionarySlimTests.cs:line 150

[jkotas]

I do not know whether this would affect performance.

Yes, it would.

[jkotas]

Related issue: https://github.com/dotnet/coreclr/issues/25

[gallivantor]

Even if it does hurt performance in the case where the exception is thrown, that is highly unlikely to be part of the critical path for any application so does it matter?

Improving messages like this, and the NRE one linked, could have big productivity wins for day-to-day development

[danmoseley]

@gallivantor it no doubt would increase the code size near to hot paths. It might also affect the code generated for the hot paths.

[GSPP]

Would it be a good idea to make the message include the index in non-optimized methods only? For debug mode.

Or, make VS show the index as part of the exception popup. NullReferenceException has a feature to show what exactly was null, which is awesome. Especially for inexperienced developers who have not yet learned to debug in a systematic way.

[danmoseley]

I don't think we're going to do this, per above.