Unconditional Code - Michael Feathers (https://www.youtube.com/watch?v=AnZ0uTOerUI)
Null Object Pattern
something bad has happened, but we’ll act like it didn’t
others: NaN, [], null, special case
that error is part of our domain
same in functional
error has moved to the place where the error occurred
when successful, do this
-–
Example
count # groups of ‘1’ (blue here)
“edgy code”, it has a lot of edge cases
add 0 at front, removes one edge
we eliminated an edge, by extending the domain
example
makes it more general, can now work with multiple files
generalizing the problem a bit, so that things that can occur can be okay
extend the range of input
so some things are not an error
not here:
we do here:
make a bet: when you extend the domain, people will understand that
2 parts of the program
- checking
- do stuff
area where there is no need of error checking
option monad in haskell, mimicked in haskell)
output =
- cumulative error message
- or
- actual output
=> mixed feeling
exceptions should be like a time machine
(like transactions)
intention can succeed or fail
example: shuffle
5 why when designing
error handling: distance between detecting problem and what you go and do about it if I can’t read a config, can I use a default config + notify?
always question errors can’t eliminate entirely but can we restructure the system so as to remove this error?
tended systems vs untended systems
supervisor trees = mimic the human
cost choice safety choice
counter-intuitive
care happens when there is hazard
vs: rust - prevent things from happening erlang - react to when they happen
