int.DivRem throws OverflowException even in unchecked context

[andanteyk]

Now, int.DivRem (and signed integer .DivRem, Math.DivRem, etc.) throws OverflowException even in unchecked context.

SharpLab

I don't think the current behavior should be changed, but I think it should at least be made clear in the documentation (int.DivRem or Math.DivRem ).

[tannergooding]

The behavior you're observing is a C# specific semantic around constant folding which the spec leaves as implementation-defined and which Roslyn has "succeeding" instead of blocking it: https://github.com/dotnet/csharpstandard/blob/draft-v8/standard/expressions.md#12123-division-operator

If the left operand is the smallest representable int or long value and the right operand is –1, an overflow occurs. In a checked context, this causes a System.ArithmeticException (or a subclass thereof) to be thrown. In an unchecked context, it is implementation-defined as to whether a System.ArithmeticException (or a subclass thereof) is thrown or the overflow goes unreported with the resulting value being that of the left operand.

The ECMA-335 runtime behavior, which is also what the .NET standard library must conform to, is stricter:

Integral operations throw System.ArithmeticException if the result cannot be represented in the result type. (This can happen if value1 is the smallest representable integer value, and value2 is -1.)

And thus, if you actually execute the code (instead of representing it in a form that allows C# to constant fold), then you will always get the overflow: This is the general behavior of division if done at runtime in any capacity: https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA0AXEUCuA7AHwAEAmABgFgAoUgRmuoEs8MACAE0YDdGBnaVgF5WcWgG5qRWgE4AFPjAALGGADWMdrOYYAdAFlmANQCGAGxwxWAeg7c+0AJQOJNGfLxKV6zdv1GzFqwApLY8/FBOLlJyCspqGlosOgAi3ABKMAC2iboGeCbmMGih9hGR1EA==

It's also worth noting that unchecked(expr) in general has no affect on method calls, only operators. Additionally, while it affects operators, it is largely only primitive types and it almost never impacts user-defined types. User-defined types must opt into user-defined checked operators which were a new feature in C# 11 (.NET 7) alongside generic math, and so not many declare or even need such operators. Further, even when some types define their own checked operators, many may still throw in various edge cases (like integer division requires).

---

Please feel free to open a PR on dotnet-api-docs adding a clarification to the exception behavior so that we can call out it always throws, as per the runtime requirements.

[andanteyk]

Thanks for the detailed explanation, I've raised a documentation update PR at dotnet/dotnet-api-docs#12354.