我是否应该在 throws 规范中声明未经检查的异常？
我知道必须处理或指定已检查的异常，但未选中的异常是可选的。
如果由于某种原因，我可以合理地预期方法中发生未经检查的异常，我是否应该将其添加到 throws 规范中？还是应该尽可能缩短规格？
答案 1
如果由于某种原因，我可以合理地预期方法中发生未经检查的异常，我是否应该将其添加到 throws 规范中？
由于未经检查的异常表示编程错误，因此应避免在子句中声明它们。通常，不应尝试捕获这些异常，除非是程序的最高级别。此规则有一些例外（双关语意图） - 例如，在生产代码中，您应该捕获 。throwsNumberFormatException
注意：有时，框架的作者会继承他们的基本异常（例如HibernateException）。像这样的例外也应该被抓住。RuntimeException
答案 2
这是一个设计决策。通常你不会这样做。但是，如果您认为代码的用户捕获 至关重要，那么这是一种提示他这样做的方法。另一种方法是将其添加到文档中，并解释为什么捕获 .ExceptionException
推荐
-
-
我们是否可以直接从服务层抛出ResponsueStatusException，而不在控制器级别抛出自定义异常和处理？ Spring 5 引入了 ResponseStatusException，直接从服务层抛出此异常是一种很好的做法。 案例1：
-
Java 7 update 25 使我们的 java Web 启动应用程序失败，没有日志记录 自 Oracle 推出 java 7 update 25 以来，我们的应用程序不再运行。 最初，我们收到了一些关于清单文件中缺少代码库和 sercurity 标记的警告，我们已修复。 我们现在最终遇到的问题是，在控制台中
-
好的模式？<X 扩展了异常> ...方法（） 抛出 X 一些背景，然后是一些问题。 我最近才发现接口（或类）可能是其方法可能引发的（已检查）异常类型的泛型。例如： 我们调用一个泛型实用程序方法（可能在外部库中定义）来运行我们自
-