3 ms·
Hi Dustin. No, those function/method calls are equivalent. My central point is that it is not reasonable to expect the consumer of a value to recover from a fa
by pgt 8y ago
Hi Dustin. No, those function/method calls are equivalent.
My central point is that it is not reasonable to expect the consumer of a value to recover from a failure mode that was generated at the producer. Rather, it is better to handle failover and retries at the producer. Of course, once a (valid) value has left your system, any downstream errors are the purvue of the subsystem, but you may want to provide a signalling pathway back to the producer if it can be resolved upstream.
This naturally results in writing thinner consuming functions and "fatter producers" or "smarter callers."[^1]
https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 https://medium.com/@dan_abramov/smart-and-dumb-components-7c...
- dustingetz 8y agonil doesn't have to be a failure mode, if we are programming with data it can just mean "empty". The trouble, I think you would point out, is that (.send bus payload) doesn't have a sensible definition of empty – because the bus reference is imperative/stateful/object oriented, not data oriented. Nil punning can't help with foreign interop to imperative systems, but that doesn't mean nil is the root cause of the pain. The imperative dependency is.