ErrLookup › Background articles › ArgumentOutOfRangeException: .NET throws it when an argument value is out of range, empty, or hits an unmapped switch case

ArgumentOutOfRangeException: .NET throws it when an argument value is out of range, empty, or hits an unmapped switch case

ArgumentOutOfRangeException is the .NET base-class-library exception a method throws when an argument's value falls outside its allowed range. Developers meet it most often as a synchronous throw at method entry naming the offending parameter via ParamName. Across the documented libraries it fires in three situations: a numeric value that went negative or oversized, a collection sized to zero where work was expected, or an enum/type value that fell through to a switch statement's default branch. The largest documented cluster is the zero-length case, where the type is sometimes used in place of the more idiomatic ArgumentException.

Distilled from 695 documented records across 43 repositories.

Background

ArgumentOutOfRangeException inherits from ArgumentException and is provided by the .NET base class library. A method throws it to fail fast when a scalar argument's value is outside the allowed range: a negative length, an index past the end, an enum member not in the defined set, or a size exceeding a fixed buffer. The thrower identifies the offending parameter through ParamName and may add a message and the actual value. It is a precondition mechanism: the method refuses to compute a meaningless or unsafe result rather than proceed and corrupt state.,The records show three shapes of this family, and the exception was designed for only the first. The numeric-range shape is the textbook one: Newtonsoft.Json's internal StringUtils.Trim rejects a negative length argument, and Orleans' EventHubQueueCache.GetSegment rejects a single Event Hub message whose serialized size exceeds the capacity of a pooled buffer block. In both cases a real value crossed a numeric bound, which is exactly what ArgumentOutOfRangeException exists to signal.,The second shape is the switch-default guard. A method dispatches over an enum or a runtime type and its default branch throws for any value the switch does not list. BenchmarkDotNet's toolchain resolver throws for a Runtime concrete type outside its six handled cases and again for a RuntimeMoniker enum value with no case; WPFUI's title-bar button maps each TitleBarButtonType to a Windows hit-test code and throws for any value that is not a defined member; Newtonsoft's BSON writer throws when it meets a BsonToken type it does not know how to serialize. These reads as an exhaustive switch that someone extended the enum or type hierarchy past. The throw is defensive, and in normal use it is often unreachable, but it surfaces whenever a newer enum member, a custom subclass, or a hand-built token reaches the switch.,The third and largest shape is the empty-collection guard, concentrated in StockSharp's GPU indicator calculators. Each calculator sizes a kernel grid and its output buffers from the lengths of the candlesSeries and parameters arrays, so a zero-length array collapses a grid axis or produces zero-sized buffers, and Calculate throws at method entry rather than launch a meaningless kernel. This shape is the family's quiet controversy. An empty array is a valid object with zero elements, so the idiomatic .NET choice for a must-not-be-empty collection is ArgumentException with a descriptive message, and several StockSharp records flag the misuse explicitly. The same codebase also has the identical guard without the flag, so the pattern is partly intentional: a single exception type for any failed precondition. Callers who need to catch these should catch ArgumentException, the shared base, to cover both the correct and the misused shapes.,From the caller's side every shape looks the same: a synchronous throw before any work is done, with ParamName naming the argument. The remedy therefore always lives at the call site or one layer upstream. Validate the value, map the enum, fill the collection, or set an explicit override so the dispatching method is never reached. The exception is library-internal contract enforcement, not a transient fault, so retrying the identical call will not help.

Common causes

What usually fixes it

Go deeper

Documented occurrences

…and 675 more across the corpus — use search.

Honest provenance: generated on 2026-08-13 from AI-assisted analysis of the linked records. See how records are made.