?p>

ㄒ槭棺远ㄒ逡斐＜坛凶訰untimeException，其原因主要有：

         RuntimeException是Spring JDBC管理事务默认执行回滚的异常，则抛出自定义异常时，

业务方法可以回滚

        在开发实践中，Service通过抛出异常来表示某种错误，Service的调用者是Controller，

为了使得全局异常处理器能处理异常，Controller也必须抛出异常，所以，抛出异常是

Service、Controller相对固定的做法，也是几乎所有开发者达成的共识，如果自定义异

常不是RuntimeException的子孙类异常，则Service和Controller中的每个方法都需要在

方法的声明上通过throws显式的声明抛出异常，非常麻烦，而RuntimeException在抛出

异常时不受到“在方法上使用throws声明抛出”的语法约束，使得起来更加方便，语法

也更加简洁

结合Spring JDBC管理事务的机制，在开发时，你应该：

        如果某个业务方法涉及1次以上（2次或多次）写操作，必须保证此方法是事务性的，建

议在业务接口上添加@Transactional注解，使得所有业务方法都是事务性的（虽可能有

不足，会使得不足2次的业务方法也是事务性的，执行效率可能略低，但相对稳妥）

         在业务方法内部，每次执行写操作时，都判断返回的“受影响的行数”是否符合预期，

如果不符合，则抛出RuntimeException或其子孙类异常，使得此业务方法回滚

强烈建议在业务中抛出自定义的异常

        如果你抛出某种已存在的异常（例如NullPointerException），你可能无法准确的区分

错误的原因，因为你认为的业务错误，和其它导致此异常的错误，都会使得你的代码在

执行过程中抛出此异常

        现有的异常可能无法准确的表示你的业务错误

在同一个项目中，可能存在多种不同原因的“失败” ，例如：

        用户登录时，用户名不存在

        用户登录时，密码错误

        用户登录时，账号已经被禁用

        其它

为了能够准确的判断导致“失败”的原因，关于自定义异常，可以：

        为每一种“失败”都创建对应的异常类，这种做法的优点是直观，每个异常类的名称就

可以表示“失败”的原因，缺点在于需要创建许多异常类，命名、管理都比较麻烦

        只创建1个自定义异常类，在类中声明区分“失败”的属性，这种做法的优点是不必创建

许多异常类，缺点是根据异常本身无法区分“失败”的原因，不如多个异常类的方式那

么直观，并且，为了更好的管理此属性的值，需要自定义枚举来清晰的表示语义