异常处理

园子里有一篇关于异常处理的文章（http://www.cnblogs.com/JacksonLin/archive/2008/07/13/1241781.html），不知道是机器翻译的问题，还是作者描述太简单，或者我的语文太差，没怎么看懂。

这里写写自己在一些项目的异常处理经验和原则，大家一起学习：

1、在哪里处理异常？在异常发生的地方还是让它冒泡到主程序？

我们的原则：永远不处理你不知道怎么处理的异常，换句话说，永远不遮掩异常。

下面的例子里面，我们在处理一个XML流，所以只捕捉XmlException，完全有可能在流里面发生其他异常，但注意不应该在这里处理它们，其实很可能我们也不知道怎么处理这些异常，多数情况下会轻易地丢弃它们。

try
{
    using (XmlReader topicReader = XmlReader.Create (xmlStream, readersetting))
    {
        // xml processing
    }
}
catch (XmlException ex)
{
    // handler xml exception only
}

联系到一个常见的问题，集中处理异常还是分散处理？我们的经验，异常应该被捕捉在能处理它们的场合，否则你很可能掩盖它们。

2、什么时候捕捉一般异常（Exception）？

我们可以经常在代码里看到：

try
{
    // 
}
catch (Exception ex)
{
    // empty code block
}

除了在主程序，永远不要捕捉它，除非你有特别的理由，因为你很可能违反了前一条，掩盖了你不知道的异常。但还是有少数情况，你需要捕捉它，一定特别说明，并在项目小组里一致通过。这个看似容易，其实很难（以我们的经验），程序员已经习惯了上述的写法，甚至变得不知道应该捕捉什么异常了，当有需要的时候，try catch block covers everything.

3、使用框架定义的异常，还是自定义的？

预定义的异常类可以满足80%的场合，但提供的错误信息并不总是能反映你的业务逻辑，这时候有必要使用自定义的异常。所以这个问题不是那么直接，要看场合。

举个例子，你的程序中收到了 'String index out of range' exception，如果没有相关上下文的信息，这样的异常信息对调试的帮助是很小的。如果我们可以提供更多业务逻辑信息（比如上下文相关变量的信息）包括在里面，对调试的帮助就大很多。

题外话，参照Java的异常设计，.NET框架中异常处理好了很多，记得M$的Channel9上有一个视频讲这个，异常处理的框架设计更合理，信息的描述更清晰、准确。

题外外话，很久没有在这里写东西了，上一篇还是两年前加拿大的时候，两年多过去了，自己也来到了雷蒙德，有些事真是很难预料。