3

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

我的服务层（使用 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 应用程序中重用这个服务层，也可以在一个安静的 Web 服务中。

什么被认为是最佳实践？

4

3 回答 3

6

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

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

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

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

于 2012-05-01T21:17:55.430 回答
1

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

于 2012-05-01T21:11:34.063 回答
0

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

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

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

于 2012-05-01T21:25:50.203 回答