关于异常的问题，写自定义方法时候，什么时候用非受检异常，什么时候不用

[zzywjing]

如题，另外在dao 、service层 怎么抛出异常。

[stacksoverflow]

受检异常，继承自Exception，如果写自定义方法中抛出此类异常，则调用者必须在写代码的时候明确处理（编译阶段）。 比如java.io.FileNotFoundException，在读文件的时候，方法就告诉你可能抛出文件找不到的异常，所以你必须对文件找不到的情况做处理，否则代码编译不过去。 非受检异常,继承自RuntimeException,如果写自定义方法中抛出此类异常，则调用者不必对此进行处理，但运行时会将此异常直接向上抛出直到有处理的地方。 比如如java.lang.NullPointerException，大部分地方都可能抛出这种异常，但你如果确定程序没问题，则不需要显示的处理，非强制性要求。 理想状态下DAO层catch住所有的DB异常,比如数据库连接异常，SQL拼写错误，然后针对不同的异常类型，在每个Catch块中生成自定义的业务异常，抛给Service层. Service层同理。 自定义异常主要考虑异常最终由谁来抓住，要做什么，比如一般画面会有通用组建，接受到什么YY异常，显示YY消息，接受到XX异常，跳转到错误页面。所以根据需要把系统异常，业务异常转化为XX异常，YY异常就可以了。 简单说受检非受检区别就是就是在写代码阶段要不要强制调用者做异常处理。 自定义异常就是将乱七八糟的系统异常进行分类，按层向上抛出，每层根据不同的分类处理不同的业务。

[stacksoverflow]

在每个Catch块中生成自定义的业务异常→在每个Catch块中生成自定义的DB异常

[stacksoverflow]

引用 3 楼 maradona1984 的回复:

实践证明,不要抛出检查性异常

不要误导，在没有充分理由证明不要抛出检查性异常的时候，请不要误导别人。 因为正常情况下这是很好的编程规范，只是大部分人图省事，没有遵守而已。

[maradona1984]

引用 6 楼 stacksoverflow 的回复:

[quote=引用 3 楼 maradona1984 的回复:] 实践证明,不要抛出检查性异常

不要误导，在没有充分理由证明不要抛出检查性异常的时候，请不要误导别人。 因为正常情况下这是很好的编程规范，只是大部分人图省事，没有遵守而已。[/quote] 最简单的方式是不抛出检查性异常,开发时不需要写try catch块,这就是足够充分的理由了 省事又达到效果,且编程/阅读代码的体验提升很多,你不需要为捕获/抛出异常编写额外的代码,减少代码的复杂度 唯一要考虑的是对调用jre/第三方代码抛出的检查性异常的处理,除了某些读取资源时抛出异常要关闭资源特别点,别的可以统一捕获然后抛出自定义的非检查型异常 跟业务异常进行区分,最后在最外层做异常处理 两种不同观点罢了,这样做好处非常明显,java的检查型异常实在太过笨重

[stacksoverflow]

引用 7 楼 maradona1984 的回复:

[quote=引用 6 楼 stacksoverflow 的回复:] [quote=引用 3 楼 maradona1984 的回复:] 实践证明,不要抛出检查性异常

不要误导，在没有充分理由证明不要抛出检查性异常的时候，请不要误导别人。 因为正常情况下这是很好的编程规范，只是大部分人图省事，没有遵守而已。[/quote] 最简单的方式是不抛出检查性异常,开发时不需要写try catch块,这就是足够充分的理由了 省事又达到效果,且编程/阅读代码的体验提升很多,你不需要为捕获/抛出异常编写额外的代码,减少代码的复杂度 唯一要考虑的是对调用jre/第三方代码抛出的检查性异常的处理,除了某些读取资源时抛出异常要关闭资源特别点,别的可以统一捕获然后抛出自定义的非检查型异常 跟业务异常进行区分,最后在最外层做异常处理 两种不同观点罢了,这样做好处非常明显,java的检查型异常实在太过笨重[/quote] 最终还是要分类处理异常，对吧。 只是你觉得把异常都放在最外面处理比较省事。 这也没错，但如果你拿到一个接口，连这个接口要抛出什么异常都不知道，又何谈处理呢？ 当然文档标记是一种方式，但这不是强制性的，强制性就是你不处理就编译不过。这是最简单的方式。 对于调用层级很深的接口，依靠文档，工具和程序员的正确性，不如依靠强制规范来的简单实在。

[maradona1984]

引用 8 楼 stacksoverflow 的回复:

[quote=引用 7 楼 maradona1984 的回复:] [quote=引用 6 楼 stacksoverflow 的回复:] [quote=引用 3 楼 maradona1984 的回复:] 实践证明,不要抛出检查性异常

不要误导，在没有充分理由证明不要抛出检查性异常的时候，请不要误导别人。 因为正常情况下这是很好的编程规范，只是大部分人图省事，没有遵守而已。[/quote] 最简单的方式是不抛出检查性异常,开发时不需要写try catch块,这就是足够充分的理由了 省事又达到效果,且编程/阅读代码的体验提升很多,你不需要为捕获/抛出异常编写额外的代码,减少代码的复杂度 唯一要考虑的是对调用jre/第三方代码抛出的检查性异常的处理,除了某些读取资源时抛出异常要关闭资源特别点,别的可以统一捕获然后抛出自定义的非检查型异常 跟业务异常进行区分,最后在最外层做异常处理 两种不同观点罢了,这样做好处非常明显,java的检查型异常实在太过笨重[/quote] 最终还是要分类处理异常，对吧。 只是你觉得把异常都放在最外面处理比较省事。 这也没错，但如果你拿到一个接口，连这个接口要抛出什么异常都不知道，又何谈处理呢？ 当然文档标记是一种方式，但这不是强制性的，强制性就是你不处理就编译不过。这是最简单的方式。 对于调用层级很深的接口，依靠文档，工具和程序员的正确性，不如依靠强制规范来的简单实在。 [/quote] 大多数异常产生就是要中断线程,少部分需要特殊处理,但这个很少 现在只需要讨论大多数场景,所以不管如何都需要抛出个异常出去,那何必自寻烦恼呢,当然异常分组是必须的,并没有多难,反正我要求每个模块都有自己的业务异常,继承一个公共的异常类,就算用错,问题也不会特别大,也就是客户端显示错误的形式不太一样罢了

[stacksoverflow]

引用 9 楼 maradona1984 的回复:

[quote=引用 8 楼 stacksoverflow 的回复:] [quote=引用 7 楼 maradona1984 的回复:] [quote=引用 6 楼 stacksoverflow 的回复:] [quote=引用 3 楼 maradona1984 的回复:] 实践证明,不要抛出检查性异常

不要误导，在没有充分理由证明不要抛出检查性异常的时候，请不要误导别人。 因为正常情况下这是很好的编程规范，只是大部分人图省事，没有遵守而已。[/quote] 最简单的方式是不抛出检查性异常,开发时不需要写try catch块,这就是足够充分的理由了 省事又达到效果,且编程/阅读代码的体验提升很多,你不需要为捕获/抛出异常编写额外的代码,减少代码的复杂度 唯一要考虑的是对调用jre/第三方代码抛出的检查性异常的处理,除了某些读取资源时抛出异常要关闭资源特别点,别的可以统一捕获然后抛出自定义的非检查型异常 跟业务异常进行区分,最后在最外层做异常处理 两种不同观点罢了,这样做好处非常明显,java的检查型异常实在太过笨重[/quote] 最终还是要分类处理异常，对吧。 只是你觉得把异常都放在最外面处理比较省事。 这也没错，但如果你拿到一个接口，连这个接口要抛出什么异常都不知道，又何谈处理呢？ 当然文档标记是一种方式，但这不是强制性的，强制性就是你不处理就编译不过。这是最简单的方式。 对于调用层级很深的接口，依靠文档，工具和程序员的正确性，不如依靠强制规范来的简单实在。 [/quote] 大多数异常产生就是要中断线程,少部分需要特殊处理,但这个很少 现在只需要讨论大多数场景,所以不管如何都需要抛出个异常出去,那何必自寻烦恼呢,当然异常分组是必须的,并没有多难,反正我要求每个模块都有自己的业务异常,继承一个公共的异常类,就算用错,问题也不会特别大,也就是客户端显示错误的形式不太一样罢了[/quote] 怎么又和中断线程扯上了，[就算用错,问题也不会特别大]这种写程序的态度我本身就不认同。 你觉得是就是吧，我只关心不要误导初学者。

[oyljerry]

https://blog.csdn.net/p106786860/article/details/11918773

[zzywjing]

来点通俗的解释

[maradona1984]

实践证明,不要抛出检查性异常 异常都需要捕获处理,但最好是在最外层统一处理,所以检查性异常就显得鸡肋,代码要难看不少 而且现在异常大多需要承担消息传递的功能,所以要自定义异常,最外层捕获异常要区分是业务异常还是其他异常,作出不同的响应

[小灰狼]

从 JDK 对异常的分类看 RuntimeException 是程序员可以通过优化程序代码来避免的异常，比如数组越界、空指针等，程序员只要多加些判断语句，就可以完全避免这类异常的发生 而非 RuntimeException 异常，是再牛B的程序员无论如何优化程序都无法避免的，比如 SocketException 异常，远程主机当机/关机、或者通信电缆被剪断……，都会导致无法与远程主机建立套接字；再比如IOException，在读本地文件时遇到磁盘坏道，导致文件读取失败、路由器故障导致与远程主机的数据通信失败……；再比如…… 建议楼主在设计软件架构时，对自定义的异常也遵循这个原则。

[大雨大雨跑]

受检异常你看看IOException是怎么做的就好，如果这里不受检异常，当发生异常后，底层逻辑是不知道怎么处理的，然后关流这些操作都没有，时间一久，资源消耗殆尽，然后你程序就挂了。
简单来说，受检异常是你必须要处理的，也就是这个程序的闭环，在各种情况下有什么动作是调用方来决定的，底层不能私做主张，这个时候就用受检

[黑街]

引用 11 楼 小灰狼 的回复:

从 JDK 对异常的分类看 RuntimeException 是程序员可以通过优化程序代码来避免的异常，比如数组越界、空指针等，程序员只要多加些判断语句，就可以完全避免这类异常的发生 而非 RuntimeException 异常，是再牛B的程序员无论如何优化程序都无法避免的，比如 SocketException 异常，远程主机当机/关机、或者通信电缆被剪断……，都会导致无法与远程主机建立套接字；再比如IOException，在读本地文件时遇到磁盘坏道，导致文件读取失败、路由器故障导致与远程主机的数据通信失败……；再比如…… 建议楼主在设计软件架构时，对自定义的异常也遵循这个原则。

那么dubbo服务提供方如何去搞错误提示呢？是错误代码？还是java的异常处理模式？哪种更好？如果是java的异常处理，是定义受检查异常？还是非检查异常？哪种更好？