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

如果用户没有权限，则抛出异常
返回某种Response对象，如果成功，则会包含新产品ID，以及成功/失败标记和错误集合。

要记住的事情：

我可以在非网络应用中重复使用此服务图层，也可以在宁静的网络服务中使用。

什么是最佳做法？

Answer 1

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

答案是否定的。服务应以一般方式暴露错误。 See this article on MSDN（不要担心这是一般性的）。在Restful服务的情况下，错误应该被传播为具有错误代码的HTTP状态。该服务不应泄漏实施细节给消费者。这是一个自然的界限。

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

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

Answer 2

问问自己你有什么其他选择，有时需要例外。你唯一能做的就是恢复失败或成功的状态并妥善处理。

Answer 3

我认为服务层应该像暴露给客户端代码的任何其他方法一样。毕竟，这正是它的本质。

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

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

服务层应该抛出异常吗？

3 个答案: