一：发现问题

先来说如何重构业务层的try{}catch{}finally{}代码块，我看过很多代码，异常处理这一块大致分为两种情况，一种是每个方法都大量的充斥着try{}catch{}finally{ }，这种方式的编程已经考虑到了异常处理，还有一种就是没有try{ }catch{ }finally{ }的代码，因为根本就没有考虑代码的异常处理。

每当我看到这样的代码，我都很忧伤。从程序的健壮性来看第一种还是要比第二种情况好，至少在编程意识中，随时想到了异常情况，有一种基本的编程思想。比如：一个业务单据的多表插入，关联修改，虚拟删除等都是一些基本的操作，但是又是比较容易引起错误的操作，在这些方法上都会加上try{ }catch{ }finally{}对代码进行有效的防错处理。早期的代码是这样的。

publicBooleanSave(AccountModel accountData)

{

    Booleanresult = false;

    try

    {

        //TODO ...

        result = true;

    }

    catch

    {

 

    }

    finally

    {

            

    }

    returnresult;

}

 

publicBooleanEdit(AccountModel accountData)

{

    Booleanresult = false;

    try

    {

        //TODO ...

        result = true;

    }

    catch

    {

 

    }

    finally

    {

 

    }

    returnresult;

}

 

publicBooleanVirDelete(AccountModel accountData)

{

    Booleanresult = false;

    try

    {

        //TODO ...

        result = true;

    }

    catch

    {

 

    }

    finally

    {

 

    }

    returnresult;

}

仅仅定义了添加，修改，删除几个空方法，就写了三四十行代码，如果业务稍微复杂些，异常处理的代码很快就会突破百行大关。虽然复制，粘贴try{}catch{}finally{}很好使，但是业务逻辑代码大量充斥着这样的try{}catch{}finally{}代码，确实显得做事不够利落。

二：解决问题

那怎样来解决这件棘手的事呢，首先定义一个公用的try{}catch{}finally{}，如下如示：

publicclassProcess

{

    

硬件app