This is what unit testing is for. Test the methods that validate and return your expected object structures. This catches other things like a structure changing (as simple as a property being modified), ensuring you can handle malformed input (even if it's valid JSON) and any other data validation rules you have.

Use a better JSON library :)

(There are competent JSON implementations, though they're few and far between. PostgreSQL's is the only good example I can point to off the top of my head.)

Here’s what Rust’s `json` crate does for the `Number` type: https://docs.rs/json/0.11.12/json/number/struct.Number.html

It stores it as positive, mantissa and exponent, allowing you to pull it apart in that way if you need to. Meanwhile, normal usage is via JsonValue (https://docs.rs/json/0.11.12/json/enum.JsonValue.html) which allows you to attempt to convert it into an f64, i32, u8, &c. as you desire, returning `None` if it doesn’t fit inside that type (e.g. -7 won’t go into an i32, 576 won’t go into a u8).

By what’s being talked about here, that looks to be a competent JSON implementation.

Wonderful. Good to know that about Rust, I haven't used it but everything I read about it looks good. Yes that is exactly the approach I meant (and a similar mechanism to that used by my own C++ JSON library I use for side projects).

Doesn't most of the Rust ecosystem use serde though?

It looks like serde-json does the same: https://docs.serde.rs/serde_json/struct.Number.html

Well, not the same; it eagerly interprets it as PosInt(u64), NegInt(i64) or Float(f64) rather than storing the mantissa and exponent. This is enough for JavaScript compatibility (its Number type being essentially a 64-bit float), but it’s not quite as flexible as the json crate’s approach.

Shouldn't they return a list of warnings/errors on the parse? Just blindly accepting a machine parse of some random input data is how you crash programs with bad input.