你的位置:首页 > ASP.net教程

[ASP.net教程]小酌重构系列[20]用条件判断代替异常


概述

异常处理的关键在于何时处理异常以及如何使用异常,有些开发者会觉得try catch的处理和使用难以把握,于是他们秉承着“您可错杀一千,不可放过一个”的想法,给所有的方法添加try catch。

这种方式会对应用程序造成什么影响吗?

从用户角度出发,用户确实难以察觉到什么,应用程序运行正常,使用的体验好像也没什么差别。

从程序角度出发,大量的try catch会降低代码的可读性,只有在异常触发时才会对程序的性能造成较大的影响。

这两种角度有对错吗?

二者都没有错,第一种角度甚至要远远高于第二种角度。

对于程序员来说,写程序开发产品的最终目的不是为了在技术上吹毛求疵,而是为了满足市场和用户的业务需求,用户并不关心产品的内部实现——用户觉得好的产品,是真正的好产品。

我们不必纠结于这两种角度的处理方式,适合自己的才是最佳的。

但是一些场景下确实不宜使用try catch

  1. 流程控制语句:流程控制有它本身的逻辑,我们应该用判断来规避try catch语句块的使用
  2. 循环控制语句:一次catch对性能的影响是较小的,但在循环中却可以积少成多,因此可能会产生较大的性能损失。

本文的主题“用条件判断代替异常”是针对场景1的,当使用try catch来控制程序流程时,如果程序中不存在“危险”代码(例如:类型转换、建立连接等),就没有必要使用try catch,我们可以直接使用条件判断来控制程序流程。

异常不发生的时候,只是给程序套了一层try{}语句块,对性能的影响微乎其微。
当异常发生的时候,进入catch语句块,CLR需要创建异常对象,保存堆栈信息,逐层查找异常表,这会较大地影响程序的性能。

异常处理是一个较大的课题,也是程序设计的一个横切关注点,本文不会对此进行深入的说明。

示例

重构前

下面这段代码表示“微波炉当前如果没有被使用,那么我们就可以用它加热食物”。

public class Microwave{  private IMicrowaveMotor Motor { get; set; }  public bool Start(object food)  {    bool foodCooked = false;    try    {      Motor.Cook(food);      foodCooked = true;    }    catch (InUseException)    {      foodcooked = false;    }    return foodCooked;  }}

这段代码通过是否触发自定义异常InUseException,来决定方法Start()方法的返回值,这是典型的使用try catch语句块来控制流程的做法。

catch语句块捕获了InUseException,却没有处理InUseException,这不仅损失了程序的性能,也未体现自定义异常InUseException的价值。
这仅仅是一个常见的逻辑判断,我们用条件判断就可以了。

重构后

重构以后,代码的可读性增强了,还消除了捕捉异常带来的性能损失。

public class Microwave{  private IMicrowaveMotor Motor { get; set; }  public bool Start(object food)  {    if (Motor.IsInUse)      return false;    Motor.Cook(food);    return true;  }}