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.

▲

pmarreck 3 days ago | parent | next [-]

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.

	▲	jpc0 3 days ago \| parent \| next [-]
		How is getting an error array not making invalid input unrepresentable. You either get the correctly parsed data or you get an error array. The incorrect input was never represented in code, vs a 0 value being returned or even worse random gibberish. A trivial example: 1/0 should return DivisionByZero not 0 or infinity or NaN or whatever else. You can then decide in your UI whether that is a case you want to handle as an error or as an edge case but the parser knows that is not possible to represent.
	▲	Ygg2 3 days ago \| parent \| prev \| next [-]
		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.
	▲	lmm 3 days ago \| parent \| prev [-]
		You parse into an applicative validation structure, combine those together, and then once you've brought everything together you handle that as either erroring out with all the errors or continuing with the correct config. It's easier to do that with a parsing approach than a validating approach, not harder.

▲

Thaxll 3 days ago | parent | prev [-]

This work if all errors are self contained, stoping at the first one is fine too.