How do you handle exceptions from API/library in your code?_问答_开发者

I have the following lines of code:

FileInfo dbFile = new FileInfo(fileName);
dbFileSize = (long)dbFile.Length / 1024;//KB

There are 8 possible exceptions from new FileInfo(fileName) and dbFile.Length calls. I cannot just ignore them. I have to catch them.

What you are going to do with those 8 exceptions? Catch them separately (too many lines)? Catch开发者_开发知识库 only ONE by catching the super Exception excepton? or ...

The correct action is to ignore them, unless you can actually fix them.

They will propagate to calling code which might be able to fix them, or log them, or something. But unless you can improve the situation at your level, don't catch them at all.

Catch them if you know what to do with them (i.e., if you can remedy the situation), or if it makes sense to handle them at your level. Otherwise, let higher-level code handle it.

Another thing. If you are going to let higher-level code handle the exception, you can also catch the exceptions and "wrap" then with a different exception object, and then throw that. The new exception should be one that makes sense in the context of the higher-level code (i.e., the code that is calling your code that uses the API). In general, this is a good method to stop details about lower-level code from "leaking" into higher levels (essentially you're stopping abstraction leakage).

As others have pointed out the general rule is: Do not catch exceptions that you cannot handle. Given that you know what to do, you should catch the 8 exceptions individually, see guidelines [1]. The reason why you should never catch Exception is that then you would also catch critical exceptions like ThreadAbortException, which you really never should do.

[1]: http://msdn.microsoft.com/en-us/library/ms229005.aspx .

For usage exceptions (like argument exceptions or null references), prevent them before they occur by enforcing assertions and checks all the way up along your call chain so that the offending input is identified as early as possible. For instance, you should require that a path typed by a user is validated before it ever gets passed into any further call. If usage exceptions do get thrown, they should not be caught (except by your final logger and polite executioner.)
For exceptions beyond your control (such as a file disappearing after you initially checked for it), handle it at the calling point if you can or require a calling method to make the check and handle it. This all depends on what it makes sense for your system to do if the file can no longer be found, for instance.

Another way to think about this to catch all exceptions where the layer above that would otherwise receive the exception does not know how to handle exceptions. I include the end-user as a "layer", and other systems that are not exception aware. So the end-user, being human (!) cannot handle an exception in its native format, so you could catch all exceptions in your code and convert them into a human friendly format, e.g., a error message on the screen. This handling code would be, e.g., in the button click event handler in a Windows form. Similarly, if the system calling your code is not exception aware, then you need to marshal the exception into a format the other system can handle. This is also the point where you would log the exception.

Otherwise, you only need to catch an exception if you can perform some kind of recovery, or you want to add further information (include the original exception as the innerException), both of which tend to be the exception not the norm.