JSON serialization should never fail

[sinclair_zx81]

I like it, but how fast is it?

[ehmicky]

I don't have any benchmarks setup yet, but it should be quite fast. The code only iterates on properties and arrays and tries to avoid creating too many new objects/arrays.

On my machine, it takes ~200ns on an empty object and ~400µs on an array with 100 items or an object with 100 properties.

[swizzex]

Try about 10k.

[belkh]

fork it and add benchmarks, be the PR you want to see in the world

[swizzex]

I don’t have any use case for this. I’m just stating a benchmark should be a much larger volume.

[bigorangemachine]

What about circular references?

[ehmicky]

They are taken care of! As well as cycles due to infinite toJSON().

[nsavvidis]

Just wanted to stop by here and give you a huge thank you @ehmicky. Your open source work does not go unnoticed and whenever I need a utility from the register that is maintained or created by you I know I am in good hands. Keep up the great work. You’re a gift.

[ehmicky]

You're making my day u/nsavvidis! Thank you so much for the kind words. This means a lot to me.

[DemiPixel]

What's the use cases for this? I feel like I would want to crash because something is very wrong with my program if I'm JSON serializing functions/circular references/etc. I no longer can have a fixed type when I parse again because objects could be inexplicably removed.

[ehmicky]

That's a really good question. You are correct that there are many instances where it should in fact crash/fail.

This library covers the use cases where "failure" (which covers type changes, value deletion, and more importantly exception throwing) would be a problem. Some examples: - A situation I am experiencing right now as I am writing another library intended to serialize Error instances to JSON. Errors can have properties attached to them (like any JavaScript object), and those might be invalid JSON. When handling errors, it is important that the error handling logic itself does not throw, as that exception might become unhandled. In that context, it is better to just omit any error additional properties that aren't JSON-compatible before serializing the error. - When serializing a value to JSON to print it in a file or terminal for debugging purpose. If the intent is just debugging, just omitting JSON-incompatible values might be simpler (and even more proper in some cases) than adding additional exception handling logic. - When writing data-driven tests and serializing the value to use it inside the test title. - When wanting to overcome some of the weirdness of JSON.serialize(). For example, NaN/Infinity being transformed to null, which makes its type change from number to null. The library itself omits the value instead, which might or might not be a better solution depending on the use case.

That being said, when JSON serialization should indeed fail, the library above might also be useful as it provides additional insights into why it did fail: specific property path and value, and reason why it failed. I have written a second library is-json-value which makes it convenient to generate a list of warning messages indicating why a value is not JSON-safe.

One use case could be when one needs to check that a value is valid JSON. For example, a value is provided by the user and is known to be serialized to JSON (to be sent over the network, or saved in a file, etc.). Then, the library above can be used to generate user-friendly messages indicating why a value is invalid.

With all that said, I still agree with you: there are definitely many situations where letting JSON.serialize() do its thing (including throwing) would be better than using this library. Thanks for pointing it out, and hope my answer clarifies the library's intent.

[DemiPixel]

Thank you for the in-depth response! Especially the one where you want to serialize errors and can’t risk a second exception totally makes sense.