2026-09-05 · 6 min read · Rahul Chitturi
- json
- numbers
- api
NaN, positive Infinity, and negative Infinity exist in many programming languages, but they are not JSON numbers. A calculation can therefore succeed in memory and fail, become null, or turn into a string when an API client serializes it.
The visible symptom may be a parser error, a schema rejection, a chart gap, or a database value that differs between services because libraries do not all handle non-finite values the same way.
Find where the value becomes non-finite
Trace the original inputs, calculation, in-memory type, serialized text, received body, and stored value. Check division by zero, invalid numeric conversion, overflow, empty aggregates, and missing sensor data before changing the transport.
- Reject non-finite results before JSON serialization
- Do not rely on implicit conversion to null or strings
- Keep missing, invalid, and unbounded meanings distinct
- Validate arrays as well as top-level fields
Define an explicit API representation
Choose a contract that fits the domain, such as null plus a status field, an omitted optional member, or a bounded string enum. Document it in the schema and make every producer and consumer use the same representation.
Avoid inventing a numeric sentinel that could overlap with legitimate data. If a scientific format needs IEEE special values, use a format and media type that explicitly supports them rather than labeling it JSON.
A Flashman workflow
Use the JSON formatter to confirm the exact wire document, diff to compare language outputs, number base converter for bounded integer fixtures, and case converter to check status-field naming across clients.
Test NaN, both infinities, negative zero, overflow, null, missing members, mixed arrays, schema errors, logs, database round trips, and every language runtime in the request path.