In C#, how do I know which exceptions to catch?

Question

I\'ve gotten in the habit of using a general catch statement and I handle those exceptions in a general manner. Is this bad practice? If so, how do I know which specific exc

Answer 1

As Kyle said, make your methods small in length, put try/catch around small areas only. Hover the mouse over the methods that you call - you should get a list of exceptions then. This will not catch every exception listed, but Exceptions can also be discovered empirically if you print the exception type inside of your catch (Exception e) { ... }. What you are after is e.GetType().FullName and e.StackTrace and e.Message and e.InnerException ... or a subset of what I listed.

Answer 2

1. Yes, except in a couple of very specific cases that's bad practice. The one common case I can think of where catching all exceptions isn't a lousy idea is when you're logging a message or a stack trace just before the app is about to tear itself down (or, maybe, you're logging and rethrowing).

2. Catch only the exceptions you know you can handle. No more, no less. If you don't know an exception can be thrown from a method, you aren't going to handle it properly anyway so don't catch it. Methods and libraries are responsible for documenting exceptions that you should be able to handle. Also, don't catch exceptions that indicate a logic failure, such as NullReferenceException and ArgumentException. These indicate a genuine bug in your software that you should fix, not something that you should handle at runtime.

Answer 3

Yes, that is bad practice. Rule of thumb: "catch the exceptions you are in a position to respond to, let the other ones go."

try {
    File.Open(usersChosenFile, FileMode.Open);
} catch(FileNotFoundException) {
    // tell the user the file is gone, give them a chance to respond
    // this is good
} catch(UnauthorizedAccessException) {
    // this is good too
} catch(Exception) {
    // what did you just catch? Who knows. What if its OutOfMemoryException?
    // Do you really want to deal with that here? Let this one go by
}

Answer 4

You must make a design decision as to whether you really need to catch all exceptions at that point in code. I know of two conditions where catching Exception makes sense:

• If you absolutely cannot allow an exception to bubble up and terminate your application.
• The calling code expect an exception to be thrown by your method/property because it is an atomic transaction. In which case, you catch all exceptions and return safely.

The downside of catching all exceptions is masking a potentially useful error message and disregarding it, causing unexpected side effects in your application.

Answer 5

Except in rare situations, I generally think of catch blocks as a code smell.

Prevent exceptions being thrown at all by checking for conditions beforehand. For example, if reading from a file, use classes in System.IO to check if the file exists, rather than using a catch block to handle the situation where the file doesn't exist.

Catch blocks should not form part of your application logic.

Answer 6

When using framework methods, you can check the MSDN documentation. Each method description has a list of potentially thrown exceptions.

As an example, check the Exceptions paragraph on File.Open() documentation.

When using your own method, you should be aware of exceptions potentially thrown by your methods.