小酌重构系列[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;
    }
}

小酌重构系列目录汇总

关注keepfool