Slide 88
Slide 88 text
● What about making impossible state unrepresentable from the beginning?
○ That’s a very good point and you should ALWAYS try to do so. The idea is to change
method’s domain definition (ie, the parameter’s shape) to only work on inputs that can’t
rise errors. Typically, in my trivial “divide” example, we should have use “non zero integer”
for denominator input.
○ Alexis King (@lexy_lambda) wrote a wonderful article on that, so just go read it, she
explains it better than I can:
“Parse, don’t validate” https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/
○ We use that technique a lot in Rudder to drive understanding of what is possible. Each
time we can restrict domain definition, we try to keep that information for latter use.
○ Typical example: parsing plugin license (we have 4 “xxxLicenses” classes depending
what we now about its state); Validating user policy (again several
“SomethingPolicyDraft” with different hypothesis needed to build the “Something”).
○ the general goal is the same than with error management: assess failure mode, give
agency to users to react efficiently.
○ There’s still plenty of cases where that technique is hard to use (fluzzy business cases…)
or not what you are looking for (you just want to tell users that something is the nominal
case, or not, and give them agency to react accordingly).
Some
questions
asked after
the talk
88