←back to thread

203 points dahlia | 1 comments | | HN request time: 0s | source
Show context
12_throw_away ◴[] No.45154518[source]
I like this advice, and yeah, I always try to make illegal states unrepresentable, possibly even to a fault.

The problem I run into here is - how do you create good error messages when you do this? If the user has passed you input with multiple problems, how do you build a list of everything that's wrong with it if the parser crashes out halfway through?

replies(6): >>45154618 #>>45154627 #>>45155518 #>>45155610 #>>45155934 #>>45156178 #
ambicapter ◴[] No.45154618[source]
Most validation libraries worth their salt give you options to deal with this sort of thing? They'll hand you an aggregate error with an 'errors' array, or they'll let you write an error message "prettify-er" to make a particular validation error easier to read.
replies(2): >>45154990 #>>45155372 #
pmarreck ◴[] No.45155372[source]
Right, but that's validation, and this article is talking about parsing (not validating) into an already-correct structure by making invalid inputs unrepresentable.

So maybe the reason why they were able to reduce the code is because they lost the ability to do good error reporting.

replies(3): >>45156653 #>>45157249 #>>45157290 #
1. Ygg2 ◴[] No.45157290[source]
Parsers can be made to not fail on first error. You return either a parsed structure or an array of found error.

Html5 parser is notoriously friendly to errors. See adoption agency algorithm.