4 ms·
Reading a lot of the responses here makes me think that there is a misunderstanding of what the author is saying. He is talking about infrastructure code, not
by tomohawk 4y ago
Reading a lot of the responses here makes me think that there is a misunderstanding of what the author is saying.
He is talking about infrastructure code, not application code. In application code, the goal is to reduce risk to your app by shedding scope so that the app only does what it needs to do to be successful.
Where does that scope get shed to? It gets shed to infrastructure.
Infrastructure code only exists to reduce risk to applications. To be successful, it has to accept risk and handle it. This requires a different way of thinking, and a different way of coding.
If an app doesn't handle an exceptional condition ok, there's someone there running it - they can just run it again. Or there's infrastructure that will run it again.
In something like zeromq, that is not a use case.
- bluetomcat 4y agoExactly this. An application implies something that has an interactive UI. Most diversions from the “happy path” can be handled by displaying a descriptive text message, informing the user that something in the environment is not right. Exceptions are a natural fit for such problem domains because the application code can be kept relatively straightforward, unencumbered by error-handling branches. OTOH, infrastructure code that runs as a service must detect every possible error as early as possible and handle it is an ordinary operating condition.