捕获异常(exception)和框架事务主动解决异常哪个更好？

在我们日常开发中，对于异常通常可以try catch去捕获异常，也可以自己使用if else 去主动规避这些异常，例如一个Order Class 的 add 方法，在操作成功的情况下返回实例，在失败的情况返回False并可以通过getError方法获取失败原因字符串，或者使用try catch去捕获这部分异常并且把异常送给用户，而且执行异常可以很轻松的处理各种异常避免我们考虑不到的情况发生，而且返回的错误代码绝对更专业，绝对是比程序员写一大堆if else更简洁和方便的多；

try catch 和 if else

参考来源：知乎

通常来说，处理不正常的情况，建议使用异常。因为异常是专为报告错误而设计的语言特性，返回值则不是。异常会有一些独有的优势。

• 向上传播异常不需要你写额外的代码。

• 异常使用的是一个独立的传播途径，不需要占用你的返回值，因此不需要专门设计特定的返回值来指示错误。

• 异常可以是一个相当复杂的对象。如果你需要携带很多信息，异常比返回值方便。

• 异常可以是类对象，而类对象拥有多态性，这方便你控制错误处理的粒度。你可以精确处理FileNotExist这样的错误，也可以简单地将IOError统一处理。

• 某些场合下（如C++构造函数）是没有返回值的，要第一时间报告错误，只能使用异常。

• 异常不能忽略，你必须处理，否则程序将会退出。返回值你不处理也不会发生什么。

不过异常也有一些劣势。

• 异常抛出点也是函数的一个出口，初学者常常忘记这一点，导致没有回收资源。你需要在写一个函数的时候，将异常也考虑进去。

• 异常在底层的实现方式，并没有统一标准。如果你混用的两种二进制代码不幸使用了不同的实现方式，异常跨界传播过程中很可能造成程序段错误崩溃。严格来说，其实返回值也有这个问题（函数调用约定），但是编译器和源代码中通常都对此做了足够的包装处理，而异常没有这个待遇。

熟悉了优劣之后，大部分情况下，建议使用异常来报告处理不正常的情况，而使用返回值来报告正常执行的结果。实际真正需要权衡和思考的问题往往不在于使用哪种设施，而在于将什么样的情况视为“不正常”。

但是，据我知悉：在Java中，像一些框架是配置了相关异常处理和异常回滚操作的，比如ssh、和ssm，当程序发生异常,如果你没有catch捕捉，程序是会抛出异常并且不再执行下去了，除了在持久化对象的set属性可以执行外，其他的操作都会回滚，这绝对是一个很好的方法，但是如果你使用了try catch去捕捉，框架就不会主动处理而回滚了并且还会继续执行，因为你捕获了这部分异常；

换句话说Java中框架和try catch是似乎互斥的，那我们有没有更好的方法在Java框架中去使用try catch去捕获并且抛出异常到页面呢？

1、Java框架处理事务是在service层，就是说能够主动处理service中发生的程序异常，那如果我们在action中捕获是不是也能达到我们的效果呢？

2、在dao和service使用 try catch,抛出异常，一层一层抛出,当然别忘了在service catch中使用 throw new runtimeException（），这样既可以保证事务发生错误实现回滚，也能捕获这些异常返回给页面。

对于这个问题，你是怎么处理？希望得到大家的评论，当然处理不当，还请大神纠正，不断学习，提升自己