3 ms·

I find the opinions presented in this article are far too common these days in completely misunderstanding exceptions. "The consequence, when you want to write

I find the opinions presented in this article are far too common these days in completely misunderstanding exceptions. "The consequence, when you want to write robust software in C#, is that you have to keep an MSDN tab open at all times. Can this method throw?" First of all, assume every method can throw. Just do it. It's either true or could be true in the future when someone changes that method. Maybe it doesn't use the network today but tomorrow it calls out to a webservice. So all methods throw. And forget knowing what exceptions they might throw. That's an implementation detail and we want to hide implementation details. "Should I catch a PathTooLongException here?" 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. Trying to play wack-a-mole is a fools errand. Put MSDN away, you don't need it.

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 ago
  If 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.
wallyhs 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. Trying to play wack-a-mole is a fools errand. I don't understand this viewpoint. If a file is locked, the user may be able to fix it, so go ahead and display an error. But if there is corruption, then what is the user going to do? You can't tell them, "Restore your system from backup, and then click OK." Your program has to crash before it causes more problems. What if the situation is stack corruption or heap corruption? Or what if the error left the application in an inconsistent state? Continuing to run might corrupt the user's data. What if an attacker caused the corruption in order to gain unauthorized access? Logging or displaying the error might be exactly what they want. I often see variations of this advice: If you don't know how to handle it, don't catch it. By definition, you don't know how to handle an unknown exception. > Put MSDN away, you don't need it. I think it is a good idea to understand the behavior and failure modes of every API function that you call; this requires that you consult the documentation.
- wvenable 11y ago
  > But if there is corruption, then what is the user going to do? Corruption is outside the state of this discussion. If half your app just overwrote the other half of your app, no matter what we say here is going to make any difference. > Or what if the error left the application in an inconsistent state? That's a good question. The other part (and in my opinion the important part) of exception handling is ensuring your stack unwinds correctly. Managed languages help this with garbage collection, resource-using statements, and finally clauses. C++ does it with RAII. This is typically just your normal resource cleanup; if you are cleaning up correctly without exceptions you'll cleanup correctly with exceptions. > I think it is a good idea to understand the behavior and failure modes of every API function that you call; this requires that you consult the documentation. You are right, of course. You should definitely know the behavior and failure modes of every framework and library you call. And you should consult the documentation for that. But what you don't need to consult (or even necessary know) is the mapping of every method to every exception. You should look at the total set of all exceptions and handle the ones you can handle.

dcsommer 11y ago

wvenable 11y ago
If 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.

wallyhs 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. Trying to play wack-a-mole is a fools errand. I don't understand this viewpoint. If a file is locked, the user may be able to fix it, so go ahead and display an error. But if there is corruption, then what is the user going to do? You can't tell them, "Restore your system from backup, and then click OK." Your program has to crash before it causes more problems. What if the situation is stack corruption or heap corruption? Or what if the error left the application in an inconsistent state? Continuing to run might corrupt the user's data. What if an attacker caused the corruption in order to gain unauthorized access? Logging or displaying the error might be exactly what they want. I often see variations of this advice: If you don't know how to handle it, don't catch it. By definition, you don't know how to handle an unknown exception. > Put MSDN away, you don't need it. I think it is a good idea to understand the behavior and failure modes of every API function that you call; this requires that you consult the documentation.

wvenable 11y ago
> But if there is corruption, then what is the user going to do? Corruption is outside the state of this discussion. If half your app just overwrote the other half of your app, no matter what we say here is going to make any difference. > Or what if the error left the application in an inconsistent state? That's a good question. The other part (and in my opinion the important part) of exception handling is ensuring your stack unwinds correctly. Managed languages help this with garbage collection, resource-using statements, and finally clauses. C++ does it with RAII. This is typically just your normal resource cleanup; if you are cleaning up correctly without exceptions you'll cleanup correctly with exceptions. > I think it is a good idea to understand the behavior and failure modes of every API function that you call; this requires that you consult the documentation. You are right, of course. You should definitely know the behavior and failure modes of every framework and library you call. And you should consult the documentation for that. But what you don't need to consult (or even necessary know) is the mapping of every method to every exception. You should look at the total set of all exceptions and handle the ones you can handle.