java - 请问业务层方法是抛出一个异常好还是返回一个结果更好

Answer 1

我的设计一般是DAO层不处理任何异常，Service层调用DAO层并捕获异常，然后通过一个状态码将信息返回给Action层。
个人觉得，Action层的逻辑尽量简单些为好，因为Action是接口层，太复杂让人难以一眼看穿接口要提供的功能。

Answer 2

错误码在面向过程的语言中非常常见，但是在面向对象的过程中，使用异常来处理多一点。
使用错误码的缺点是：
1、对错误的检测不是强制的
2、代码充斥各种if else的错误码判断
使用异常的好处是：
1、对错误的检测是强制的，你必须处理或者上抛异常
2、代码不必对各种状态码进行判断，有异常直接抛出终止往下运行
3、对于错误有堆栈可以追踪。

Answer 3

库抛异常，业务返回错误码。

Answer 4

我觉得这主要看两点：1各层的逻辑量的轻重，则需要你自己取舍；2个人风格，我比较喜欢能在业务层处理的尽量处理，但dao层只抛异常。其实哪里处理都行，只要不直接返回给客户端就好。

Answer 5

业务层都是if else 基本都是调用数据 返回前应该设置默认值比如空值 只有dao类可能与业务层之外的系统交互,数据库,网络 出现异常的概率更大,所以应该在dao类里面妥善处理异常 业务层/ action返回空值/缺省值 这样对用户更友好

Answer 6

持久化这块一般不进行逻辑处理，往上一级抛最好，不然以后要改用一些持久化框架了移植起来太麻烦
虽然造成异常的情况有很多，但对用户的结果来说就是没成功，至于为什么没成功是留给开发人员看的，所以我认为不用返回这么多种结果，直接返回异常开发人员通过查看哪种异常也能判断原因
我想你要记录这个应该是用来判断如果出错了是哪里出错是吧，打印日志应该是一个挺普遍的做法，把异常之类的加入到日志里

Answer 7

嵌套了多少层？
先学会减少嵌套吧

另外service层就是返回确定的结果，它就是处理异常和业务逻辑的
action层起到路由的作用，调用该调的service直接返回就好

Answer 8

我在知乎问过这个问题：https://www.zhihu.com/question/36278363
敬请参阅。

Answer 9

你这个例子无所谓，
但是存在事物的情况下，就有所谓了，
如果你使用的是申明式事物，那么事务中的某一个中间环节出错，因为错误直接抛出，所以可以在事务开启的那一层被catch到，并回滚当前事务中所有的操作，
如果你在dao曾捕获了异常，那么感知这个业务是否需要回滚就变得很麻烦，需要对每一个dao操作结果进行判断。