←back to thread

Stop writing CLI validation. Parse it right the first time

(hackers.pub)
203 points dahlia | 2 comments | 06 Sep 25 18:20 UTC | HN request time: 0s | 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 #
ffsm8 ◴[07 Sep 25 04:59 UTC] No.45155518[source]▶
I think you're looking at it too literally - what people usually mean with"making invalid state unrepresentable" is in the main application which has your domain code - which should be separate from your inputs

He even gives the example of zod, which is a validation library he defines to be a parser.

What he wants to say : "I don't want to write my own validation in a CLI, give me a good API already that first validates and then converts the inputs into my declared schema"

replies(2): >>45155854 #>>45157423 #
1. 8n4vidtmkvmk ◴[07 Sep 25 06:21 UTC] No.45155854[source]▶
Zod might be a validation library, but it also does type coercion and transforms. I believe that's what the author means by a parser.
replies(1): >>45156900 #
2. goku12 ◴[07 Sep 25 10:08 UTC] No.45156900[source]▶
Apparently not. The author cites the example of json parsing for APIs. You usually don't split it into a generic parsing into native data types and then validate the result in memory (unless you're on a dynamically typed language and don't use a validation schema). Instead, the expected native data type of the result (composed using structs, enums, unions, vectors, etc) is defined first and then you try to parse the json into that data type. Any json errors and schema violations will error out in a single step.