Question

After writing code that can be boiled down to the following:

var size=-1;
var arr=new byte[size];

I was surprised that it threw an OverflowException. The docs for OverflowException state:

The exception that is thrown when an arithmetic, casting, or conversion operation in a checked context results in an overflow.

I couldn’t see how providing a negative size for and array length fits into the description given for this exception, so delved a little deeper and found that this is indeed the specified behaviour:

The computed values for the dimension lengths are validated as follows. If one or more of the values are less than zero, a System.OverflowException is thrown and no further steps are executed.

I wonder why OverflowException was chosen. It’s pretty misleading if you ask me. It cost me at least 5 minutes of investigation (not counting my musings here). Can anyone shed any light on this (to my thinking) peculiar design decision?

Answer 1

This is almost certainly an optimization. The .NET framework code is pretty religious about checking arguments to let the programmer fall in the pit of success. But that doesn’t come for free. The cost is fairly minuscule, many class methods take lots more machine cycles than is spent on the checking.

But arrays are special. They are the very core data structure in the framework. Almost every collection class is built on top of them. Any overhead put in the Array class directly impacts the efficiency of a lot of code that sits on top of it. Avoiding the check is okay, it gets implicitly checked anyway when the internal code needs to cast the value to unsigned. And it is very rare that it trips. So checking it twice is not quite worth the better exception message.