>>>It appears that now when I add new features, I am more careful relying on Try/Catch. The old code was not as "clean". So, it creates a lot of maintenance work.
>>
>>Code may be "clean" but "fault-tolerant" is another concept. It's a real rabbit hole trying to write fault-tolerant code for unreliable environments.
>
>My goal is to create an system that will log errors - even if caused by the faulty network - and minimize users' run-time errors. That is, I want to be able to show to the IT issues without "troubling" the end-user.
>Does it make sense?

User run-time errors:

- The number they see will not decrease unless you implement fault-tolerance, and those changes are able to retry or reconnect silently
- You can control the experience they have. If it's caused by an unrecoverable network error you can give them a message something like

"We're sorry, the application has encountered an unrecoverable network error and must be closed. Information has been logged for troubleshooting purposes. Please contact tech support. If the network error is temporary, you may try again later."

The users may be annoyed that something went wrong, but they're reassured that something is being done about it.

This can also get the users enrolled in leaning on IT support to get the network fixed ;)