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

1) checking

2) 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