4 ms·

Appropriate time is quite often at the end of the unit of work. Let’s say, your microservice is doing some interactions with database and querying another servi

Appropriate time is quite often at the end of the unit of work. Let’s say, your microservice is doing some interactions with database and querying another services. If an unlikely I/O error happens, DB will take care of the uncommitted transaction and your service is just fine with returning HTTP 5xx. Probability of this happening and impact of not implementing error handlers all over your stack are very low. Since the majority of developers are not writing perfect programs, they will not spend the money/time to avoid this risk. Exceptions may not help writing a better program, but they are practical enough to be supported in the language.

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 ago
  There'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 ago
    Yup. 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.

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 ago
There'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 ago
  Yup. 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.