←back to thread

Stop writing CLI validation. Parse it right the first time

(hackers.pub)
203 points dahlia | 1 comments | 06 Sep 25 18:20 UTC | HN request time: 0.478s | source
Show context
12_throw_away ◴[07 Sep 25 01:29 UTC] 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 ◴[07 Sep 25 01:45 UTC] 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 ◴[07 Sep 25 04:21 UTC] 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. lmm ◴[07 Sep 25 11:25 UTC] No.45157249[source]▶
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.