问题标签 [checked-exceptions]

我正在阅读一篇关于 Java 中已检查和未检查异常的文章，并找到了这篇文章/链接： https ://projectlombok.org/disableCheckedExceptions.html

根据这篇文章，它只是为 javac 开发的一个 hack。

考虑下面的代码片段：

在这里我必须写 public static void main(String args[]) throws IOException ，因为我正在尝试打开一个文件。这里“抛出”子句是必须的。没有它我会得到一个错误。如果我确定我正在打开的文件的存在怎么办。iemyfile.txt 在提到的位置。在某些时候，人们会感觉到代码不需要很少的 Checked Exceptions。

Java 是否提供了任何工具来根据需要禁用已检查的异常？

即使做了这么多的研究，我也找不到合适的答案。

我正在尝试使用Durian library的 Errors 类来捕获 Java 8 的 lambda 函数中的检查异常。

我写了简单的函数：

并试图称之为：

此代码运行良好：

但是此代码调用编译器错误方法 wrap(Throwing.Function) 对于类型 Errors.Rethrowing 不明确

我不明白为什么。

我从这里得到了例子：https ://github.com/diffplug/durian/blob/v2.0/test/com/diffplug/common/base/ErrorsExample.java

榴莲版本：com.diffplug.durian 3.4.0

我倾向于尽可能多地进行检查Exceptions：它使代码变得杂乱无章（我认为检查Exceptions是 Java 的一个可疑方面）。我倾向于在“优化”代码时使用它们。即，当它对特定上下文有意义时。

当覆盖不抛出所需的超类/接口方法时，这种方法会稍微复杂一些Exception，因此我倾向于这样做：

where_close是处理所有业务的私有方法。

当涉及到 JUnit 时，如果你真的想测试抛出异常的东西，_close()那么结果RuntimeException似乎是由 JUnit 以“无条件”的方式处理的：它似乎总是以失败消息停止测试。 ..即使你真的抓住并处理它try .. catch！

我发现了一种“解决方法”（CUT 类在关闭closeableComponents时将其全部关闭）：

即，如果您没有此expected设置，您总是会遇到测试失败（因为RuntimeException“忽略” try .. catch）。但是为了满足expected你必须RuntimeException在测试结束时重新抛出...

...有什么方法可以改变 JUnit 的处理方式RuntimeExceptions吗？

在以下代码中：

我正在尝试捕获检查的异常并处理它。在我的情况下，它将是 FileNotFoundException，但我不知道为什么它从不运行我试图打印消息或任何其他功能的 catch 块，但它似乎跳过了。谢谢

SO上有很多关于“已检查与未检查异常”主题的帖子。这个答案可能是最全面和信息最丰富的。然而，我仍然对遵循那里提出的逻辑感到矛盾，这是有原因的。

我正在围绕一组彼此相似的服务构建一个包装 API。但是，它们之间存在细微差别（或将来可能出现这种差异），因此某些功能（次要和快捷性质）可能由某些服务支持而其他服务不支持。因此，采用以下方法似乎是合乎逻辑的：

为什么UnsupportedOperationException？因为它正是为这种情况而设计的。

但是，除了 Oracle自己的手册之外，所有相关的 SO 帖子都假定，如果使用异常来表示客户端可以从中恢复的问题，或者是可预测但不可避免的问题，那么该异常应该是经过检查的异常。我的案例符合这些要求，因为对于某些操作，可能会提前知道它们不可用的可能性，并且这些操作并不重要，如果需要可以避免。

所以我迷失在这个难题中。我应该使用完美匹配的标准异常并违反异常使用的常见逻辑，还是应该构建自己的检查替代方案，从而重复代码并在 API 用户之间造成额外的混乱？

根据[1]，

“在决定检查异常与未检查异常时，问问自己，当异常发生时客户端代码可以采取什么行动？如果客户端代码不能做任何事情，请将其设为未检查异常。如果客户端代码将采取一些有用的根据异常中的信息进行恢复操作，使其成为受检异常。”

我得到了整体的想法。但是，我的困惑是，“客户端代码”是什么意思。假设我正在编写一个 REST API，它有一个调用实际后端层的服务层（我也在其中进行验证）。

1. 那么API用户也被认为是“客户端代码”？
2. 对于请求验证，我应该抛出 Checked 还是 Unchecked Exceptions？
3. 避免使用检查异常的最佳做法是什么？
4. 是否可以在验证中抛出未经检查的异常，让它冒泡，然后在服务层的自定义异常中捕获和包装它？（并使用 JAX-RS ExceptionMapper [3] 向 API 用户展示）

参考：

[1] http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html

[2] http://archive.oreilly.com/pub/post/avoiding_checked_exceptions.html

[3] https://docs.oracle.com/javaee/6/api/javax/ws/rs/ext/ExceptionMapper.html

考虑下面的 Java 代码片段：

这在 Eclipse（Neon.2，JDK 8）中使用 SonarLint 执行静态代码分析。它提供了重构的建议：

重构此方法以最多抛出一个已检查异常，而不是：java.lang.InstantiationException、java.lang.IllegalAccessException

此建议的基础是什么最佳实践？我知道通常对检查的异常存在一些争议，但是为什么在这种情况下在这里捕获一个并将另一个传递到堆栈而不是将它们都传递到堆栈以供其他东西处理它们会更好？

我编写了我自己的两个自定义异常，一个是选中的，另一个是未选中的，当我执行我的代码时只显示选中的异常为什么我无法获得未选中的异常输出？

上述程序的输出是： Got Checked Exception ，但我期待输出Got Checked Exception && Got Unchecked Exception。我在这里犯了什么错误？我该如何克服呢？

到目前为止，我认为每个 Java 异常都必须由构造函数在某处创建，因为我可以自己创建自定义异常：

但现在看来我必须处理来自 JavaMail - MessagingException的一些异常。它来自方法（从类Store.close继承）。Service

我去了那里（我需要检查什么时候抛出这个异常，这样我才能知道哪里出了问题），我看到这个方法调用了另外两个方法——它们都没有抛出异常！

据我了解，这是检查异常（既不是错误也不是 RuntimeException），那么它怎么可能不必在close方法命令使用的任何一个中声明呢？它也不是在此方法中创建的。

又是一个德尔福新手问题。是否有指定方法引发的异常的标准方法（我已经用谷歌搜索过，但除了处理异常的基础知识之外似乎找不到任何关于该主题的内容）。

换句话说，在函数/过程签名中是否有一种标准的方式来表示“我的函数/过程可以抛出这个特定的异常”（我假设没有）。那么让 API 的客户端知道给定过程/方法将引发哪种异常的最佳实践是什么？