Math.abs and ordinary integer arithmetic can silently overflow. How does this happen, and what does Math offer to detect it?

## Fixed-width integers and wraparound A Java `int` is stored in **32 bits**, so it can represent only the range **-2,147,483,648 to 2,147,483,647** (that is, -2^31 to 2^31 - 1). A `long` is 64 bits with a correspondingly larger but still finite range. When an arithmetic result is **larger than the maximum** (or smaller than the minimum), Java does **not** throw an error. Instead it **wraps around** using **two's-complement** representation — the bits that don't fit are discarded and the value silently becomes something else, often a negative number. Example: ``` Integer.MAX_VALUE + 1 == Integer.MIN_VALUE // wraps from +2^31-1 to -2^31 ``` This is *silent overflow*: the program keeps running with a corrupted value, which can become a subtle bug or even a security hole (e.g. a size calculation wrapping negative and bypassing a bounds check). ## The `Math.abs(Integer.MIN_VALUE)` trap `Math.abs` is supposed to return the magnitude — a non-negative number. But: - `Integer.MIN_VALUE` is `-2^31`. - Its positive counterpart would be `+2^31`. - The largest positive `int` is only `2^31 - 1`. So `+2^31` does not fit, and `Math.abs(Integer.MIN_VALUE)` returns `Integer.MIN_VALUE` again — a **negative** result from `abs`. The same is true for `Math.abs(Long.MIN_VALUE)`. This is the canonical example that `abs` is not guaranteed non-negative. ## The exact-arithmetic methods To make overflow **loud instead of silent**, `Math` provides *exact* methods that throw `ArithmeticException` when the mathematically correct result wouldn't fit: - `Math.addExact(a, b)` - `Math.subtractExact(a, b)` - `Math.multiplyExact(a, b)` - `Math.incrementExact(a)` / `Math.decrementExact(a)` - `Math.negateExact(a)` - `Math.absExact(a)` *(throws instead of returning the negative MIN_VALUE)* - `Math.toIntExact(long)` — narrows a `long` to an `int`, throwing if it doesn't fit Each has `int` and `long` overloads. Instead of a corrupt value you get an immediate, catchable exception — turning a silent data-integrity bug into a fail-fast error. ```java int sum = Math.addExact(a, b); // throws ArithmeticException if a+b > Integer.MAX_VALUE ``` ## Floor division and modulo A related pair handles a different surprise. Java's `/` and `%` **truncate toward zero**, so `-7 / 2 == -3` and `-7 % 2 == -1`. When you want division/remainder that rounds **toward negative infinity** (often what you want for wrapping indices or time buckets), use `Math.floorDiv(-7, 2) == -4` and `Math.floorMod(-7, 2) == 1`. `floorMod` always returns a result with the **sign of the divisor**, which is handy for non-negative modular indices. ## When to use which - **Performance-critical inner loops where overflow is provably impossible** → plain `+`/`*`. - **Counters, sizes, allocations, IDs, financial integer math, anything user-influenced** → the `*Exact` methods, so a wrap becomes an exception rather than a silent corruption (this is also a security recommendation). - **Wrapping/circular indices or negative-operand modulo** → `floorDiv` / `floorMod`. - **Genuinely unbounded values** → `BigInteger` (arbitrary precision, never overflows). The exact methods add a tiny overflow check (a branch), which is negligible compared to the cost of a silent integer-overflow bug.