服务层应该抛出异常吗？

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 的 create 方法中的选项：

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

要记住的事情：

我可能会在非 Web 应用程序中重新使用此服务层，也可以在 Restful Web 服务中使用。

什么被认为是最佳实践？

Answer 1

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

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

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

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

Answer 2

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