Web 应用程序中的 Java Spring 错误处理性能

Question

这专注于后端 Web 应用程序开发。我更喜欢在我的应用程序中使用映射到我的业务逻辑的 HTTP 状态代码。例如，如果发出请求但未找到用户，我将抛出异常并使用 @ControllerAdvice 处理它。或 @ExceptionHandler并映射到 404 未找到。有时我在 try catch block 中有这些用于记录并重新抛出异常。我更喜欢这种方式，因为 API 的实现者可以只查看状态代码并继续前进，如果它是预期的客户端错误，则无需反序列化。一位同事认为，如果它是应用程序的预期状态，那么一切都应该是 200，其中包含失败原因的响应正文而不是预期的响应对象，因为执行 catch block 是一项昂贵的操作。我个人不喜欢这种方法，因为您的 API 的实现者必须检查响应实体并尝试将其反序列化为预期的对象，或者如果失败，请将其反序列化为某个已知的异常对象，因为它总是 200。

TLDR:我的问题是我看到很多关于为什么根据堆栈跟踪执行 catch block 可能很昂贵的文章，并且错误处理不应该是控制流的一部分，但我很难同意这一点，因为 Spring 有@ControllerAdvice 等功能, @ExceptionHandler或更新的 ResponseStatusException .我也不同意 HTTP 状态码指的是协议(protocol)，而 200 只是意味着成功传输的说法。如果是这种情况，那么 401 和 403 应该是 200，因为响应处理得很好，客户端只是没有授权或正确的授权。这个论点对我说，一切都应该是 200，为什么还要使用其他状态码？我还处于职业生涯的早期，所以如果我遗漏了一些明显的东西，请原谅。

Answer 1

首先，您不能在每种情况下都跳过 try-catch block 。如果你的代码抛出了一些异常，你应该清楚地知道那些已知的异常，以便完全处理不间断的服务或阻止应用程序发生意外行为。如果您必须捕获或处理异常，则捕获并处理它。

关于处理异常的成本:

永远不要尝试在 catch block 中编写太多的业务逻辑。只需保持简单并处理或传播它。没有什么可担心的成本。在服务器应用程序中，有时您必须通过捕获异常并为此编写适当的日志来跟踪故障。此外，“尝试”几乎没有任何费用。代码的元数据不是在运行时设置 try 的工作，而是在编译时构建的，这样当抛出异常时，它现在执行一个相对昂贵的操作，即向上遍历堆栈并查看是否存在任何可能的 try block 捕获这个异常。

关于，HttpStatus代码:

Http 不会强制你申请 200 作为成功的状态码。您还可以使用 401 或 403 作为响应代码。 Http有一些标准。喜欢(400 表示错误请求，403 禁止)如果你不遵循它没有害处。但是，您正在打破标准。例如，您为我提供了一个返回 JSON 作为响应的 API。但是，我希望成功操作 200。如果您将 401 设置为您的成功代码，我将不得不面对一些困境才能找到问题。所以，最好还是遵循标准。