是抛出异常，还是约定返回值？

[finemi]

就拿业务层来说，我定义了一个Result类，来作为业务层方法的通用返回值，保存正常业务处理中所遇到的一些详细信息返回

public class Result<T> {
	private boolean success;//成功与否
        private int errorCode;//错误代码
	private String message;//错误信息
	private T result;//保存需要的返回数据
}

两种方式：
1.业务层不处理Dao数据层的异常，在servlet中捕获这些异常，并判断返回值result类的各种错误信息
2.业务层将数据层的所有异常捕获，转化到为Result返回值中作为另外一种errorCode，这样servlet不再需要捕获异常，统统只判断Result的errorCode

这两种方式哪种好？有没有更好的解决方案？

[rumlee]

个人认为第二种方式更优

[engourdi]

我用的第二种，写API的时候第二种感觉更好统一处理。

[attilax]

这个问题其实总结有俩个？？ 一、异常还是返回值 二、本层处理还是抛出上层处理 根据异常方面的使用准则，答案是：： 1．普通项目优先使用异常取代返回值，如果开发类库方面的项目，最好异常机制与返回值都提供，由调用者决定使用哪种方式。。 2．优先把异常抛出到上层处理。。异常本身就是为了方便把异常情况抛出到上层处理。。 当然根据一些特殊情况可以还有其他方式来处理。。但并非将来的主流趋势...需要注意。。 1.对于方法调用结果异常情况返回策略，最终会有四种策略状况， 抛出异常excepttion、返回特殊值、阻塞、超时 2 2.4. 常见的捕获异常后的处理策略 2 4.1. 转换为业务异常，抛出至上层处理（常用） 2 4.2. 根据异常种类处理异常（常用） 3 4.3. 事务rollback 3 4.4. 日志记录，重新抛出 3 4.5. 忽略异常（很少这样处理） 3.参考 Atitit.常见的捕获异常后的处理策略总结 atitit.架构设计---方法调用结果使用异常还是返回值

[attilax]

从开发效率，灵活性考虑。。可以根据情况适当转换异常（不要使用返回值），继续抛出到sevlet层,这样可以：： 方便aop filter对异常做处理。分层处理。 可以容易实现配置化的异常处理。。