Hacker News Reader

Comment by nicoburns | Hacker News Reader

> The parser will not complain about leading zeros because JSON has no concept of leading zeros.

Of course there is no logical reason why the parser shouldn't have this concept just because the spec doesn't require. IMO, beyond basic correctness, user friendly error messages are the main differentiator between excellent parsers and crappy parsers.

View on HN

Browser JSON parsers probably shouldn't be optimized for user friendliness, since to the users running the program any error message is going to be unfriendly. They are optimized for speed, and if nice error messages slow thing down at all, then bare messages it is.

Maybe there's a way to re-parse with a friendly parser with there's an error and dev tools is open.

In a language I worked on ( github.com/skiplang/skip ), at the moment where we throw a syntax error, we can look at the previous few tokens and generate much better error message.

In the case of the above, if last is ], previous is number and before is 0, then put a nice error message where octal notation is not allowed.

This is not “pure” from a language theory sense but in practice if you add a handful of common ones, it makes for a much better experience.

I agree. Often, it's much easier to generate good diagnostic messages by adding failure paths to lexer or parser definitions. i.e. in the 01 case, add a rule for numbers with leading zeroes to the lexer, which generates an error explaining that leading zeroes are prohibited.

When your inputs are from real JSON emitters, it is silly to even have error handling other than rejection.

Helpful error messages for humans writing JSON is a special use case, not "the main differentiator" marking an "excellent [parser]".

Exposing a "helpful" JSON parser to the internet is a bad idea, and probably a waste of electricity, since the error messages will likely go into a black hole. An "excellent" parser might even reject some technically valid forms, for not being regular (indicating a suspicious or malfunctioning client).

> When your inputs are from real JSON emitters, it is silly to even have error handling other than rejection.

I'm guessing from this that a "real JSON emitter" is one that perfectly implements the JSON spec and has absolutely zero bugs? Does such a thing exist?

> Exposing a "helpful" JSON parser to the internet is a bad idea, and probably a waste of electricity, since the error messages will likely go into a black hole.

There's a lot of software where any kind of unexpected error just gets repeated back to the user. I'm sure you've seen a modal popup like:

    Unexpected error, please try again 
    (SyntaxError: JSON.parse: expected ‘,’ or ‘]’ after array element)

This is immensely unhelpful to basically everyone involved. If the message at least hints that it's due to a problem with the input itself -- for example: "SyntaxError: Invalid value ‘01’" -- then it's much more likely that an end-user can figure out which value is causing the problem and work-around it, and report a much more meaningful bug to the developer (thus allowing it to be solved significantly faster).

Taking the argument that "helpful" JSON parse errors are pointless to its logical conclusion, there should only be a single possible error "JSON parsing failed", and I can't see how that's anything but a recipe for making everyone absolutely despise your API/product/etc, especially were your JSON parser ever to have even a single bug that caused that response erroneously.

>I'm guessing from this that a "real JSON emitter" is one that perfectly implements the JSON spec and has absolutely zero bugs? Does such a thing exist?

If the JSON Serializer has a bug then the only option is to fix the bug instead of adding a human that is manually correcting mistakes in the generated JSON output. The only purpose of human friendly errors is because humans are involved and since they aren't we have to unnecessarily add them to make your complaint valid. (Don't tell me you're feeding the human friendly error messages into an ML algorithm. That's just bullshit.) The days of office workers doing pointless busywork of this type are long gone.

I'm not sure why you're saying humans aren't involved. Humans are writing the code (often with bugs), troubleshooting operations, supporting other humans using the software, and identifying and fixing bugs.

While I agree fixing the bug is the only option, it still has to be identified first. A bug that is based on data can appear to happen "randomly" and if the error is a useless one like the OP or even just "invalid JSON" it can take a long time before isolating the exact cause (especially if it's not obvious which piece of software is even the source of the error), and in that time end users, support and ops people lose trust in the system.

If your environment's JSON serializer is fundamentally capable of producing invalid JSON in normal operation, you probably have a lot of other problems to overcome.

Hey look, it's Maurice Wilkes...

Reporting the last valid input and the start of the first invalid location (possibly repeating the first couple characters of invalid content, filtered for safety) is what I'd generally prefer in an error message.

For some reason the author truncated the error messages reported by Chrome and Firefox to not include the line/column.

The message in Firefox is: JSON.parse: expected ',' or ']' after array element at line 1 column 3 of the JSON data

In Chrome: Unexpected number in JSON at position 2

Showing the boundary between accepted and rejected input is indeed a good idea.

The case discussed in the article would benefit of a display with spaces between tokens.

Example: Source: [01] Compiler error: [ 0 1 ] ----^ SyntaxError: JSON.parse: expected ‘,’ or ‘]’ after array element

Such situation of two tokens without a separator character becomes much more obvious.

Notice also the character showing point of error. OCaml has been doing for a while ( https://ocaml.org/learn/tutorials/common_error_messages.html now shows underlined parts) then clang, cf. https://clang.llvm.org/diagnostics.html . This is much quicker for the human to communicate, than "line x column y".

> user friendly error messages are the main differentiator between excellent parsers and crappy parsers

It think parser quality is a matter of correctness, error messages, speed, and resource use. How much each of these are to be prioritized depends on application. I'm entirely with you that most of the time error messages matter a lot and are often worse than they should be.

Sadly user friendly error messages are often main differentiator between low-performance parsers and high-performance parsers.

Probably not for any great reason: worst case scenario is to simply use the fast parser, and when it fails, then go back to the end of the last successfully parsed expression, and run the the slow parser to get a good error.

That is, it's not terribly difficult to deal with the tradeoffs if your description of the problem is at all correct

Reply on news.ycombinator.com