3 ms·
This absolutely works for a HTTP request handler, where all the error handling is implemented in the DB / garbage collector, and where we're dealing with almost
by jstimpfle 6y ago
This absolutely works for a HTTP request handler, where all the error handling is implemented in the DB / garbage collector, and where we're dealing with almost perfectly isolated processes.
In more complex systems, this won't work out. Imagine a software that controls sensors and motors, for example. What if one of these devices fails? There is no way any automatic system (like exceptions) could come up with the right way to handle this situation.
- ivan_gammel 6y agoThere's no silver bullet that would solve error handling in such cases purely by the means of the programming language. Just like it's possible to have memory leaks in Java, it is possible to write broken code with Either<Result, Error> - imagine accidentally ignoring an error from sensor that results in overheating and fire. If you want to absolutely make sure, that this won't happen, then you build your system in a way, where prevention of the exceptional situations is implied by design, rather than requires an additional effort from developer.
- jstimpfle 6y agoYup. To continue with this example, an approach that often works is to simply not have any error. For sensor readouts, request new samples to be reported asynchronously. (Coincidentally this is better for performance as well). In this way, the client code is basically required to think -- oh, wait, what happens if I'm not getting updates for some time beyond what is acceptable for me? Also, in this way, the situation can be handled in a single central location.