异常处理

园子里有一篇关于异常处理的文章(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上有一个视频讲这个,异常处理的框架设计更合理,信息的描述更清晰、准确。

题外外话,很久没有在这里写东西了,上一篇还是两年前加拿大的时候,两年多过去了,自己也来到了雷蒙德,有些事真是很难预料。
posted @ 2008-07-14 04:00 dawave 阅读(...) 评论(...) 编辑 收藏