In JavaScript, which operations produce Infinity and which produce NaN? Explain the rules with examples.

## Saturation, not exceptions IEEE-754 defines what happens when a floating-point result cannot be represented, and JavaScript adopts it wholesale: arithmetic never throws for a numeric range problem. Overflow saturates to a signed infinity, underflow collapses to a signed zero, and operations with no defensible answer produce NaN. Nothing in that chain raises an exception, so the failure travels silently into whatever consumes the result. ```js Number.MAX_VALUE * 2; // Infinity 1e309; // Infinity — even the literal overflows -1e309; // -Infinity 1e-400; // 0 — underflow -1e-400; // -0 — underflow keeps the sign ``` ## Division by zero Dividing a nonzero finite number by zero gives an infinity whose sign is the combined sign of the operands: ```js 1 / 0; // Infinity -1 / 0; // -Infinity 1 / -0; // -Infinity -1 / -0; // Infinity ``` This is the point most often mis-remembered by people arriving from languages where integer division by zero throws. In JavaScript there is only one numeric type here and only one behaviour: a signed infinity. ## The indeterminate forms NaN appears when the mathematical answer is genuinely undetermined — where you cannot pick either a finite value or a signed infinity without lying: ```js 0 / 0; // NaN Infinity - Infinity; // NaN Infinity * 0; // NaN Infinity / Infinity; // NaN Math.sqrt(-1); // NaN Infinity % 2; // NaN ``` Contrast `1/0` (a definite magnitude direction: unbounded, positive) with `0/0` (any value could be argued for). That distinction is the rule worth carrying: **a definite direction gives an infinity; no defensible answer gives NaN.** ## Infinity as a value you can use `Infinity` is a global property, non-writable and non-configurable since ES5, and `Number.POSITIVE_INFINITY` / `Number.NEGATIVE_INFINITY` name the same values. `typeof Infinity` is `"number"`, and it compares as you would hope: `Infinity > Number.MAX_VALUE` is true, and `-Infinity` is below every finite number. That makes the infinities useful as sentinels: ```js let best = Infinity; for (const item of items) { if (item.cost < best) best = item.cost; } ``` The same reasoning explains the spec's odd-looking defaults: `Math.max()` with no arguments returns `-Infinity` and `Math.min()` returns `Infinity`, because those are the identity elements — anything you subsequently compare against them wins. That behaviour also means `Math.max(...arr)` on an **empty** array yields `-Infinity` rather than throwing, which is a real source of "where did -Infinity come from?" bugs in aggregation code. ## Detecting and guarding `Number.isFinite(x)` is true only for a Number that is neither NaN nor an infinity, so it is the single guard that covers all three problem values. `Number.isNaN(x)` is not enough on its own: an overflowed computation is `Infinity`, which is not NaN and would pass that check. ```js function safeRate(distance, seconds) { const rate = distance / seconds; return Number.isFinite(rate) ? rate : null; } safeRate(10, 0); // null — was Infinity ``` The global `isFinite` exists too, but it converts its argument first (`isFinite("100")` is true), so prefer the `Number.` method. ## Where infinities cause trouble downstream An `Infinity` that escapes a computation tends to surface far away and in a confusing shape. It renders as the string `"Infinity"`, which fails most numeric parsers on the receiving side. It also does not survive JSON: `JSON.stringify` writes non-finite numbers as `null`, so an `Infinity` sent over the wire silently arrives as `null` and the original overflow is unrecoverable. And an infinity that later participates in a subtraction or a multiplication by zero degrades into NaN, at which point even the sign is gone. The defensive habit is the same as for NaN: check with `Number.isFinite` at the boundary where a computed number leaves its module, so the value is rejected while you still know which computation produced it.