3 ms·

I would expect the JSON-decoding library to do one of the following, depending on the library author's or callee's wishes: - output a floating-point value with

I would expect the JSON-decoding library to do one of the following, depending on the library author's or callee's wishes: - output a floating-point value with some lost precision - output an arbitrary-precision integer, or some general "number" type that can be an arbitrary-precision integer or double-precision float - output an "integer too precise to decode" placeholder in that location in the data structure - fail to decode the document entirely In no case should it crash. I don't know what you mean by "a machine integer with the overflow flag set", since it doesn't exactly work that way, so the "integer too precise to decode" value is my alternative. For example, suppose you're making a "JSON document"-based database engine and its query language only supports double-precision numbers. In that case, I would output a correctly-rounded floating point value, if I were decoding JSON. Usually in other cases of decoding an integer, unless you're hosting an arbitrary precision integer calculator web application, there should be maximum acceptable values on any integer you'd read off the wire. For example, there's a maximum data size, maximum timeout duration, and such.

lmm 12y ago
Punting the choice up to application code is not a good idea; maybe you should allow them to override the config, but good defaults are important.
- nly 12y ago
  The only sane default is to return an arbitrary precision arithmetic type with an optional mode for truncation to double for performance.
derefr 12y ago
> fail to decode the document entirely [...] in no case should it crash Note that I was using the Erlang sense of "crash"—a crash from a pattern-matching failure is the default clause of most case statements, and you want those to be bubbled up by crashing linked and supervising processes until they hit something that has generic "something went wrong; I'm going to report this to the user" code in it (like e.g. Rack does in Ruby.) You don't want to specifically be throwing, immediately catching, and then converting exceptions into 500 errors in every part of your code. Also, I was assuming in this example that you're using a modern web framework, where the JSON decoding is handled by the framework—not by you—so the framework likely doesn't expose any configuration for something like its JSON deserialization library, which it wants you to just consider an implementation detail. So you won't get to specify anything like "maximum data size". Instead, the JSON library needs to "just work" in all cases, returning its best-effort interpretation of the wire message to you. (The parallel for HTML parsing would be libraries like Beautiful Soup.)

lmm 12y ago

Punting the choice up to application code is not a good idea; maybe you should allow them to override the config, but good defaults are important.

nly 12y ago
The only sane default is to return an arbitrary precision arithmetic type with an optional mode for truncation to double for performance.

derefr 12y ago

> fail to decode the document entirely [...] in no case should it crash Note that I was using the Erlang sense of "crash"—a crash from a pattern-matching failure is the default clause of most case statements, and you want those to be bubbled up by crashing linked and supervising processes until they hit something that has generic "something went wrong; I'm going to report this to the user" code in it (like e.g. Rack does in Ruby.) You don't want to specifically be throwing, immediately catching, and then converting exceptions into 500 errors in every part of your code. Also, I was assuming in this example that you're using a modern web framework, where the JSON decoding is handled by the framework—not by you—so the framework likely doesn't expose any configuration for something like its JSON deserialization library, which it wants you to just consider an implementation detail. So you won't get to specify anything like "maximum data size". Instead, the JSON library needs to "just work" in all cases, returning its best-effort interpretation of the wire message to you. (The parallel for HTML parsing would be libraries like Beautiful Soup.)