4 ms·
> No, you shouldn't. What are you going to do any differently with that than you would FileIsLockedException or NetworkIsDownException or HarddriveIsCorruptExce
by dcsommer 11y ago
> No, you shouldn't. What are you going to do any differently with that than you would FileIsLockedException or NetworkIsDownException or HarddriveIsCorruptException? You wouldn't do anything differently. Show the user the ErrorMessage in the dialog and allow them to restart whatever operation was in affect. Let them choose a shorter path, close Excel, plug their Ethernet cable back in, or whatever.
I don't think this approach works in general. Server software, at least, needs to automatically handle all these different failure modes in potentially unique ways.
- wvenable 11y agoIf you are aware of particular situation, you can handle it. If you aren't aware of a particular situation at best you log the problem and skip the operation. That's pretty straight forward and is still the same approach. For example, I might just catch every single Network exception, log it, add a timeout, and retry the operation. I'm not playing wack-a-mole and I don't care in the handler which of the thousands of methods called in my operation actually raised the exception. The point is one should not be looking at what exceptions the methods throw but instead what exceptions can be handled. One set is very large the other set is very small. This applies equally well to server software.