SSM中异常怎么处理，包括io,net,业务异常?

建议Dao层,直接往上抛异常(一般都是数据库的运行时异常),Service层因为是暴露给其它应用的,并且会有很多业务信息需要传递给上层的调用者,所以这里有两种方式

1. 通过抛出业务异常来,告知调用方具体的业务异常信息/系统异常信息(系统异常,上层可能不会关注)

2. Service中保证不会出现异常,并且返回一个Result给上层,Result里面包括的信息有:这次调用是否成功,如果失败会有一些业务信息

所以不用层层都去抓异常,如果要处理就在Service中处理(不管是单应用还是以后的服务化),具体在service中是以上述的哪种方式,具体看团队的选择了

大体的业务流程我们是用try{}catch{}来控制,还是用if()来控制,方法中是通过throw，throws异常还是返回一个带错误码的Result来处理业务流程中的异常，和返回值

在开发中 ，这个直接影响到程序的健壮，扩展，和可读性。

1.比如说用户查看某些内容,我们要判断他是否有权限查看,这个时候我们应该是定义一个异常来处理,还是直接if()来处理?
2.catch{}有规范说抛给哪个层统一处理吗?还是根据实际情况各各层处理?
3.网上说try{}catch{}会对性能有影响,影响究竟多大?

这个问题本质应该是想问这两种控制流程到底有什么区别,就像Vicky和iMouseWu解释的那样,比如说try{}catch{}会交给JVM,这样做是提高了程序的健壮性,还是提高了程序的XX,请各位答主先抛弃try{}catch{}只能用来处理异常的想法再回答该题.

如果各位还有更好的回答,我会继续关注,采纳各位的答案,共同学习

看上面回答都是一致使用错误码来控制业务流程,我来说说我自己的想法

什么是异常?

An exception (or exceptional event) is a problem that arises during the execution of a program. When an Exception occurs the normal flow of the program is disrupted and the program/Application terminates abnormally, which is not recommended, therefore these exceptions are to be handled

按照这个解释,我们是不是也可以把业务上的错误当做一个异常流程来处理？

所以当业务上出现比如题主说的「没有权限访问」,可以抛出一个异常。当然也可以通过接口返回错误码的方式完成。

换个角度来看这个问题,来看下Java API中的一段代码

 public String getCanonicalPath() throws IOException {
    if (isInvalid()) {
        throw new IOException("Invalid file path");
    }
    return fs.canonicalize(fs.resolve(this));
 }

那我们能不能把这个接口改成用错误码的方式来传递错误信息呢,当然也是可以的。至于Java API为什么在这里选择了用异常而不是用错误码,我想你也不希望你在你的代码的中需要对很多方法进行错误码判断吧,而我们的业务接口相对少一点,所以如果用错误码不会显得十分臃肿。

至少到现在为止可以得出一个结论结论:用异常或者用错误码来控制业务流程都是可取的,只要整个团队统一风格就OK了。

回到题主的问题上来,用异常来控制业务流程和用错误码来控制到底有什么优点和缺点。

1. 用错误码控制业务流程,需要对每个接口的返回都要做一个错误码的校验,判断的代码会遍布在你的业务代码里面。优点就是对调用方,不必对你的接口进行异常校验,因为你的接口只可能返回「正确」或者「错误」,在效率上面也会更加高一点。对某些人来说,用错误码来控制业务流程更能符合「异常」的语义。

2. 用异常来控制业务流程,可以把错误处理集中在一处,对客户端的代码编写更加友好,在业务代码里面不会有很多错误码的判断。缺点就是创建异常堆栈是需要时间和空间的,但是可以通过子类覆盖父类的fillInStackTrace来解决。

参考

异常(exception)和执行失败有什么区别
LongjumpsConsideredInexpensive
Exceptions or error codes