关于错误处理

Exception Handling Best Practices in .NET
By Daniel Turini

Rule 1 Don't throw new Exception()
 Exception is a too broad class, and it's hard to catch without side-effects. Derive your own exception class, but derive it from ApplicationException. This way you could set a specialized exception handler for exceptions thrown by the framework and another for exceptions thrown by yourself.
要有自己的错误处理类，这样可以对framework的异常和应用程序自己抛出的异常分别处理－－其实错误类应该有一些基本的自定义属性，譬如ID，错误类别，错误级别...等这些信息吧

Rule 2 Don't put important exception information on the Message field
 Exceptions are classes. When you return the exception information, create fields to store data. If you fail on doing it, people will need to parse the Message field to get the information they need. Now, think what will happen to the calling code if you need to localize or even just correct a spelling error in error messages. You may never know how much code you'll break by doing it.
不要把一些错误的关键字都放到Message中，以免后面又要解析Message－－这个原则一般都会遵守的吧，譬如错误的种类和错误的ID这些信息就不应该放到Message中去吧。

Rule 3 Put a single catch (Exception ex) per thread
 Generic exception handling should be done in a central point in your application. Each thread needs a separate try/catch block, or you'll lose exceptions and you'll have problems hard to understand. When an application starts several threads to do some background processing, often you create a class for storing processing results. Don't forget to add a field for storing an exception that could happen or you won't be able to communicate it to the main thread. In "fire and forget" situations, you probably will need to duplicate the main application exception handler on the thread handler.
每个线程都有自己的异常捕捉

Rule 4 Generic Exceptions caught should be published
 It really doesn't matter what you use for logging - log4net, EIF, Event Log, TraceListeners, text files, etc. What's really important is: if you caught a generic Exception, log it somewhere. But log it only once - often code is ridden with catch blocks that log exceptions and you end up with a huge log, with too much repeated information to be useful.
错误信息应该有记录－－这也是为了以后维护的方便，日志还是很有必要的

Rule  5 Log Exception.ToString(); never log only Exception.Message!
 As we're talking about logging, don't forget that you should always log Exception.ToString(), and never Exception.Message. Exception.ToString() will give you a stack trace, the inner exception and the message. Often, this information is priceless and if you only log Exception.Message, you'll only have something like "Object reference not set to an instance of an object".
日志应该记载全部的错误信息，而不是Message。

Rule 6 Don't ever swallow exceptions
The worst thing you can do is catch (Exception) and put an empty code block on it. Never do this.
不要在catch中什么都不作

Rule 7 Use exceptions for errors that should not be ignored
 I'll use a real world example for this. When developing an API so people could access Crivo (my product), the first thing that you should do is calling the Login method. If Login fails, or is not called, every other method call will fail. I chose to throw an exception from the Login method if it fails, instead of simply returning false, so the calling program cannot ignore it.
在函数调用中不要仅仅返回成功还是失败，应该返回错误

Rule 8 Don't clear the stack trace when re-throwing an exception
 The stack trace is one of the most useful information that an exception carries. Often, we need to put some exception handling on catch blocks (e.g., to rollback a transaction) and re-throw the exception. See the right (and the wrong) way of doing it: The wrong way: try
{
    // Some code that throws an exception
}
catch (Exception ex)
{
    // some code that handles the exception
    throw ex;
}

Why is this wrong? Because, when you examine the stack trace, the point of the exception will be the line of the "throw ex;", hiding the real error location. Try it.

try
{
    // Some code that throws an exception
}
catch (Exception ex)
{
    // some code that handles the exception
    throw;
}

What has changed? Instead of "throw ex;", which will throw a new exception and clear the stack trace, we have simply "throw;". If you don't specify the exception, the throw statement will simply rethrow the very same exception the catch statement caught. This will keep your stack trace intact, but still allows you to put code in your catch blocks.
在嵌套throw中不要throw老的exception！！！

Rule 9 Avoid changing exceptions without adding semantic value
Only change an exception if you need to add some semantic value to it - e.g., you're doing a DBMS connection driver, so the user doesn't care about the specific socket error and wants only to know that the connection failed.

If you ever need to do it, please, keep the original exception on the InnerException member. Don't forget that your exception handling code may have a bug too, and if you have InnerException, you may be able to find it easier.

尽量不要增加自己的语义到错误信息里去，但是如果需要，则最好保存innerexception，而不是exception，这样有利于你最快的发现错误所在