服务层应该抛出异常吗？

Question

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

我的服务层（使用 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 的创建方法中的选项：

1. 如果用户没有权限，抛出异常
2. 返回某种 Response 对象，如果成功，它将具有新产品 Id，以及成功/失败标志和错误集合。

注意事项：

我可能会在非网络应用程序中重用这个服务层，也在宁静的网络服务中。

什么是最佳实践？

Answer 1

取决于您所说的服务和异常的含义，但在您所了解的上下文中，我将假设来自 HTTP 端点的 Java 异常。

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

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

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

这是一篇很好的文章，更详细地解释了这一点：https://learn.microsoft.com/en-us/archive/blogs/rjacobs/restful-services-and-business-exceptions

Answer 2

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

Answer 3

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

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

其他客户端，例如 REST，无论如何都应该通过其他包装层（例如

Controller

层）访问服务层。包装层的职责之一是将响应转换为客户端可消费的。