关于异常的处理一些问题之我见

1.异常处理的好处在绝大多数的情况下都是大于坏处,请尽量使用异常处理.

2.如果要针对单独一种异常进行了try...catch处理后,最好外面再要外包一层try...catch去捕捉未知的异常(或者用一个try,多个catch,而最后一个catch就是用来catch未知异常),因为你永远都不不能保证你的程序在哪里抛出何种异常,正如引用文章那个中所说的OutOfMemoryExcetpion等异常是很常见的,想象一下有过万行的数据转化成Excel报告这样的情景,抛出这个异常就不足为奇了,因为我就遇到过.^_^

3.try...catch要包装尽量少的代码吗? 显然,没有发生异常的时候,基本是没有什么性能损失的,决定要不要这样做,其实得看情景的,例如一个很简单可能发生除零错误的代码块,就可以很明确的只try...catch这一段,让人更明确这里到底会出什么问题,同时告诉人家你已经对预计中的问题都做了处理了.但这种完美的情况基本上都是不存在的,所以说尽量try更多的代码,catch更多的异常显得更重要,因为一些已经知道的异常,为什么还要你try呢?何不自己就静悄悄的处理掉呢?是吧 ^_^

4.底层的框架类库尽量少用try...catch吗? 底层的框架类库通常比较通用,性能的要求也比较高,所以只在总接口中使用try...catch?这也许是很多人的一些误解,他们或者会认为有了总接口中做了异常捕捉就可以万事大吉,因为异常是会一层一层网上抛出来的,所以有异常可定能捕捉到.但实际中如果这样操作会出现很多问题.因为这样很不利于程序的排错,特别是在一些时间比较紧要求并行开发(类库和业务代码同时进行开发)的项目中,到了代码会师那一刻,代码有bug,排错就很困难,因为catch到已经是穿过几个时空后的原始人,都不知道他是来自那个世纪的^_^,所以其实底层更需要try...catch.

5.catch中不要包含业务逻辑! 有些朋友喜欢在异常处理模块中把业务包含进去,但这样其实有很大的隐患的. 我曾经看到过这样的一个例子,有个业务逻辑是要判断用户是否设置了某个时间,然后用这个时间进行其他处理,这里那位哥们使用一个省劲的方法,就是先把取出来的值做时间转换,能转就是有定义,不能转抛出异常就判断用户没有定义这个时间,这样做初初看上去好像问题也不大,但是日后如果客户要投下业务变动的原子弹,后果是如何,大家想像一下就知道,这里引用句经典话,"谁用谁知道啊" ^_^

6.尽量"throw;",不要"throw e;". 这两者有什么区别呢,如果使用"throw e;"只是单纯把捕捉到的异常抛出来,其实还有一些存在与堆栈中的信息没有被抛出来,所以throw出来的东西是经过过滤的,如果大家是要向上一层进行throw,就要来得彻底点,不然又可能会给排错加上一层不该有的迷雾的哦 ^_^

7.catch中如果要写log,请把当前StackTrace也要拉进来. 因为把StackTrace记录下来,可以获取一些对排除异常很有帮助的信息,例如引发这个异常的调用的事件和函数列表等,想象一个经过多次throw才catch的异常,有这个瓜藤,就不怕摸不着瓜啦,是吧 o(∩_∩)o

参考文章:关于.NET的异常处理的几个误区