2

根据[1]，

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

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

API User --calls--> { |Service Layer| --internally calls--> |Backend Layer| }
  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

4

1 回答 1

4

Q1：那么API用户也被认为是“客户端代码”？

是的。

Q2：对于请求验证，我应该抛出 Checked 还是 Unchecked Exceptions？

引用您问题中的建议：“如果客户端代码无法执行任何操作，请将其设为未经检查的异常。如果客户端代码将根据异常中的信息采取一些有用的恢复操作，请将其设为已检查异常。”

Q3：避免使用检查异常的最佳做法是什么？

不。

Q4：是否可以在验证中抛出未经检查的异常，让它冒泡，并在服务层的自定义异常中捕获和包装它？（并使用 JAX-RS ExceptionMapper [3] 向 API 用户展示）

“可以吗”取决于你问谁。这还取决于它是否适合您。

如果您将所有内容都变成未经检查的异常，那么编译器将无法通过检查应该处理的异常是否已处理来帮助您。

在您的模型中，必须将需要由客户端 API 调用者处理的错误与不需要处理的错误区分开来。可以做到……但是您更依赖于 API 客户端程序员来知道什么是正确的事情。如果没有检查的异常，他/她可以简单地忽略异常......直到它们导致系统测试失败，生产失败。

你的程序员有多好？你的文档有多好？您的质量控制/测试制度有多好？

于 2017-03-19T02:42:32.797 回答