> I/O errors, especially network errors, are things that are going to be expected under reasonable operation, therefore it make sense that code should handle th

> I/O errors, especially network errors, are things that are going to be expected under reasonable operation, therefore it make sense that code should handle them It makes some sense, but often, code should do relatively little and process should do most of the handling. Recovering from I/O errors and properly testing the recovery code can take huge amounts of time and effort. Often, aborting the program and rerunning it or even restarting a service is the best way to handle these because properly handling them in code costs time better spent on other things. Logging a decent error message and aborting may be the better choice. But of course, that depends on the use case. Databases need lots of recovery code for I/O errors and deadlock recovery, for example, even for cases that occur maybe once every year. (And yes, process nowadays is often automated, making it code again, but IMO, that’s a different kind of code)