>>>>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 ;)

Let me describe one - kind of typical - error the application was encountering and which, last night, I "fixed".

When the application closes, one method closes the handles and deletes the files "user001.inf" and "user001.log" These files are created on a user entry in the application and store who is in the application and at what time he/she started.
If the desktop has a problem with the network, on closing the handles (to the above files) and erasing them, the run-time error was created: "cannot access file user001.inf" (something like that).

I enclosed the entire code that closes the handles and erases the files in Try/Catch with the entry written in the log. So, from now, the user will not be alerted of the run-time error. This is not so important that these files are closed and erased. They will be closed and erased on the next entry of the user into the application.

These are the paces (among others) I want to "fix" by using Try/Catch and minimize the run-time error. Even though, the run-time error happens not because of the bug in the code (I have those too :)