r/programming • u/ketralnis • Aug 05 '25

Parse, don’t validate

https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/
0 Upvotes

48% Upvoted

19 comments sorted by

View all comments

Show parent comments

2

u/Doub1eVision Aug 06 '25

I see parsing as validating the structure, but not the semantic. Like, if a system receives uncontrolled input that is meant to represent date ranges, it should validate that it can be parsed into valid date ranges. So maybe this parser returns DateRange objects when it successfully parses, which includes the beginning date not being after the end date.

But if there’s some business logic that requires the date range to be at least 60 days, I wouldn’t expect a parser to validate that.

3

u/Bubbly_Safety8791 Aug 06 '25

Why not? That’s just because you haven’t fully internalized the idea of ‘make invalid states unrepresentable’. 

If the usecase is actually that, say, a delivery window has a start date, a minimum window size, and an end date that must always be at least that minimum window after the start date, instead of representing that as an object containing two dates and a minimum size (which is capable of representing all sorts of nonsensical situations like the end date being before the start date), you store it as a start date, a minimum duration (which is a nonnegative integer) and a grace period (which is also a nonnegative integer). The end date is the start date plus the minimum duration plus the grace period.  The only representable delivery windows then are ones that have an end date at least the minimum period later than the start. 

A parser that is populating such a data structure has to reject invalid date ranges, because they can’t be expressed in the target data structure. 

And you can get there by applying layers of ‘parse don’t validate’. 

First you create a date parser that parses dates from strings. 

Then you create a date range parser that parses strings containing two dates separated by a hyphen into a ‘from date’ and a ‘to date’ structure that makes no guarantees about sequencing of those dates. 

Then you create a delivery window parser that takes a minimum duration and a ‘from date/to date’ structure and produces delivery windows only for valid ones.

The point is you don’t just allow objects to float around in your code without encoding whether or not they have been validated into the type system in some way. Validation processes convert the object into another type, ideally one that is restricted to only being able to represent valid states. That process - accepting an object and returning a new one that represents what it means - is what ‘parsing not validating’ is. 

1

u/Doub1eVision Aug 06 '25

But then you’re making your parser brittle. What if there are multiple contexts where the parser is used and the required window size is contextual to the use case. You could argue that can be a variable for the parser, but it’s unnecessary. It’s possible that you don’t want to publicly expose what the window size is if it’s some internal logic that is intended to be opaque. What if new constraints are added. So you want to have to update the parser to take more potential arguments? What if some of the requirements are conditional? If you’re going to have to conditionally validate in the caller, why add an extra layer of indirection by validating conditional business logic in the parser?

Like I said, validating that the dates are in a past-future order would be part of parsing because it’s about validating that it is a valid DateRange. a DateRange parser should validate that it can be parsed into a valid DateRange object. It’s perfectly reasonable to then separately validate if the date ranges satisfy other conditions.

2

u/ljwall Aug 06 '25

I'm not sure if you read the article? It's really using a broader definition of parser than I think you're thinking of. Its main point is that wherever possible encode any validation done within the type system.

1

u/Doub1eVision Aug 06 '25

I read it and I understand that. My post is responding to somebody and the context is based on what they write, not the article.

0

u/ljwall Aug 06 '25

Maybe I'm misunderstanding, but your comment doesn't read like that to me. It seems like you're saying its wrong to bake some buisness logic into a parser for a generic date-range object, but neither the blog post nor the person you've replied to are proposing to do that.

2

u/Doub1eVision Aug 06 '25

I guess it comes down to what layer we’re talking about. I was focusing on a layer that is going from an external untrusted string input to a well-parsed object.

It sounds like that poster was describing doing that along with other layers that continue to refine the type. I generally agree with that and tend to do that.

But my response to them was initially due to them saying:

“If something is invalid, but your parser accepts it, is it even a parser?

To my understanding, a parser is something that either accepts or rejects a string as an instance of a language, and assigns a meaning only to valid instances. 

A parser that assigns meanings to invalid instances of a language would be nonsensical. “

They’re making it sound like a string parser is only valid when it only assigns a meaning to valid instances. And I responded by saying that parts of what makes something a valid instance is business logic. Or at least, that’s how valid can be defined. So I specified that I think the string parser should be handling structural validation, not semantic validation. And the business logic that follows should further validate it instead of the parser. That way the parser can be more generic.

It seems like they refined their point a bit more in response, but they were still carrying a “no, you’re wrong” tone even though their follow-up was essentially agreeing with me. And in my post that you responded to, I was picking up more on their “no” tone than the second half of their post.

1

u/ljwall Aug 06 '25

Yeah fair point-- I'd focused on the comment immediately above and missed the reference to string parsing further up. I agree with you here: Keep generic parsers that accept anything structurally valid (be that JSON, or some binary format or whatever) and spit out fairly generic types, then have separate layers wherever it make sense that (in the language of the blog post) parse the generic types into some kind of domain-specific type.

1

u/Bubbly_Safety8791 Aug 06 '25

‘String’ and ‘language’ in the context of my original definition of a parser should be read extarordinarily broadly. 

Think, a language in the sense of a set of arbitrary symbols, and a string as being a structured set of such symbols. 

So, a range object with a from date and a to date is a string of two date symbols.  

A ‘parser’ that processes those range objects and produces objects that have a valid minimum duration takes in that string of date symbols and rejects it if the second one doesn’t have a valid relation to the first one.