>>>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?

It does - in my book, as I still follow "offline first" mindset, albeit ISPs and Telco will insist that mindset is from a millenium looong time ago... It helps when testing the client is not only connecting via Virtualbox internal network switch, but instead calls into different PC server boxes where you can introduce network errors by unplugging a cable instead of messing with config files or router settings like WLAN on/off, DHCP, IP #, device name, DNS via ruled proxy, kickout at certain times... ;-)

If WLAN or mobile is in the possible loop, add a hint to err mess on checking that as automatic switch to another WLAN might have happened due to location/signal strength difference plus visiting coffee maker...