The point is not to handle individual bugs, it is to handle all failures. This is the difference between a "defensive programming" approach and the "let it cras

The point is not to handle individual bugs, it is to handle all failures. This is the difference between a "defensive programming" approach and the "let it crash"/ "zen of erlang" approach. Actors are designed such that they have failure isolation, which means they can react to errors in other actors without worrying about their own state. They then have two options based on one of two bug classes - transient and persistent. Persistent errors are propagated to the supervisor. Transient errors are either retried or propagated. It doesn't matter if it's a network error, a disk error, a timeout, a crash, a cosmic radiation bit flip - your approach is always one of those two. So adding more failure cases doesn't "matter" in terms of your error handling, although you may want to adopt helpful patterns in the nuances of "retry". The frequency of errors will obviously increase with a network error (arguably very very little), but the pattern is fundamental to resiliency. If your network is truly so unreliable that you can not pay that cost, don't do it. I don't think most people are developing on networks that fail for long periods of time frequently.