服务层应该抛出异常吗？答案

【问题标题】：Should Service layer throw an exception?服务层应该抛出异常吗？
【发布时间】：2012-05-01 21:09:39
【问题描述】：

出于某种原因，我不喜欢抛出异常，也许是因为我不知道对性能的影响，想知道我是否应该重新考虑这个问题。

我的服务层（使用 Dao 的 + 业务逻辑等）应该抛出异常吗？

public ModelAndView createProduct(@Valid ProductForm productForm, ..) {
  ModelAndView mav = new ModelAndView(...);

  if(bindingResult.hasErrors()) {
     return mav;
  }

  // throw exception if user doesn't have permissions??
  productService.create(product, userPermissions);

}

所以我在 ProductService 的 create 方法中的选项：

如果用户没有权限，则抛出异常
返回某种类型的 Response 对象，如果成功，该对象将具有新产品 ID，以及成功/失败标志和错误集合。

注意事项：

我可以在非网络应用程序中重用此服务层，也可以在静态网络服务中。

什么是最佳实践？

【问题讨论】：

标签： java spring spring-mvc soa

【解决方案1】：

取决于你所说的服务和异常是什么意思，但在你所拥有的上下文中，我将假设来自 HTTP 端点的 java 异常。

答案是否定的。服务应该以一般的方式暴露错误。在 Restful 服务的情况下，错误应该作为带有错误代码的 HTTP 状态传播。服务不应该将实现细节泄露给消费者。这是一个自然边界。

消费者应该处理这些错误情况，并决定最合适的沟通方式。它很可能会选择生成异常。但是这些异常与导致服务返回错误代码的原始问题/接收不相交。

更进一步，我会说@yahir 他所说的也是正确的。 HTTP 服务会暴露 HTTP 错误，它很可能只是在下面使用另一个服务返回另一种错误，但它的工作将是适当地处理或映射它们。

【讨论】：

链接现在失效了
因为该文章已被清除而被删除

【解决方案2】：

问问自己还有哪些其他选择，有时例外是必要的。您唯一可以做的另一件事是返回失败或成功状态并进行适当处理。

【讨论】：

【解决方案3】：

我想说服务层的行为应该与暴露给客户端代码的任何其他方法一样。毕竟，就是这样。

将通过 RPC 使用它的客户端将完全期望这种行为。

其他客户端，例如 REST，无论如何都应该通过其他包装层（例如Controller 层）访问服务层。包装层的职责之一是将响应转换为客户端可使用的。

【讨论】：