Overflow, Underflow, and Parse Errors

Learning Objectives

By the end of this lesson you will be able to:

Distinguish between numeric overflow, underflow, and parse error
Predict which failure mode a given input will trigger
Design tests that specifically target each failure mode

The Three Failure Modes

When an extreme numeric value is submitted to an application, one of three things happens:

1. Parse Error

The input cannot be interpreted as a number at all.

Examples: abc, 1.2.3, 1e (incomplete), 1,000,000 (comma in wrong locale)

Result: Exception during parsing, before any arithmetic. The application should return HTTP 400 with "Invalid number format."

2. Overflow

The input is a valid number but exceeds the capacity of the storage type.

Examples: 1e400 for a double field, 3000000000 for an Int32 field

Result: Either the number is stored as Infinity (float), wraps around (int), or a range error is thrown. The application should return HTTP 400 with "Value exceeds maximum limit."

3. Underflow

The input is a valid number but is so small it rounds to zero in the storage type.

Examples: 1e-400 for a double field

Result: The value is stored as exactly 0.0. No error is thrown. This is dangerous — the system accepted an input but stored a different value (zero) than what was entered.

Distinguishing Between Them

Input	Likely Failure Mode	Signal
`abc`	Parse Error	Exception during parsing
`1.2.3`	Parse Error	Exception during parsing
`1e999`	Overflow → Infinity	No exception; result is Infinity
`3e9` (as Int32)	Overflow → exception or wrap	Depends on language
`1e-400`	Underflow → silent 0.0	No exception; result stored as 0

The Underflow Is Most Dangerous

Parse errors and overflow both typically produce some visible signal (exception, error response). Underflow produces nothing — the value is silently stored as zero.

This creates a "phantom zero" in the system — a value that the user didn't intend but that the system happily stored. If any subsequent calculation divides by this value, you get division by zero.

Testing All Three Modes

Test	Input	Expected Behavior
Parse error	`abc`	HTTP 400, "Invalid number format"
Overflow float	`1e400`	HTTP 400 or Infinity (document which)
Overflow int	`3000000000`	HTTP 400 or overflow (document which)
Underflow	`1e-400`	HTTP 400 or stored as zero (document which)

Pro Tip: When you find that 1e-400 is stored as 0.0 without error, that's a defect worth reporting even if the application doesn't crash. The system accepted a non-zero value but stored zero — data integrity violation.

Key Takeaways

Parse error: input isn't a number → should be caught before arithmetic
Overflow: number too large for type → may be Infinity, exception, or wrap
Underflow: number too small for type → silently rounds to 0.0
Underflow is the most dangerous because it produces no signal