通常我尝试只在“异常”情况下使用异常(“Effective Java”，第 69 期)。我个人的解读是: 如果我在代码的特定部分(通常是方法或构造函数)中遇到无法再给出有意义的答案或结果的情况，我将抛出异常，调用这段代码的人必须处理它。
在 HTTP 端点的特殊情况下，我总是可以给出有意义的答案 - 带有状态代码的响应。 因此，处理错误请求属于端点方法的正常程序流程，不应引发新的异常。
例如返回资源的端点应该只返回 404，以防找不到资源。在我看来，引发“SomethingNotFoundExcetion”(可以由错误处理程序处理并创建 404 响应)是不好的做法
我的问题是:使用 Spring Boot 的错误处理机制来处理依赖于异常来创建特定 HTTP 响应的错误请求 (4xy) 是不好的做法。 (对于所有未发现的错误产生 500 真的很好)
(我只是在写代码审查，我不确定我是否应该建议不要将错误处理程序用于“正常”API 交互)
对当前答案的回答/评论
看来你们中的大多数人都错过了我推理的重要部分: (引用 Effective Java，第 69 项):
Use exceptions only for exceptional conditions ...
this reasoning: • Because exceptions are designed for exceptional circumstances, there is little incentive for JVM implementors to make them as fast as explicit tests. • Placing code inside a try-catch block inhibits certain optimizations that JVM implementations might otherwise perform.
我的主要观点是:
A well-designed API must not force its clients to use exceptions for ordinary control flow.
特别是在 rest API 的情况下。以完全避免异常的方式使用任何 API 应该很容易。这对我来说意味着。 Rest API 的正确使用(例如在 Open API 中定义)不应引发异常。
换句话说:SOAP 标准(另一种基于 http 的 API 东西)禁止对正确的(由 WSDL 定义的)请求使用“SOAP 错误”。
对我而言，在非异常情况下在远程 API 中引发异常比在经典 API 中(通过依赖)更糟糕。
最佳答案
这取决于您的项目，这实际上是一个意见/架构决策问题。我会说非此即彼。
使用特定的 Exception 然后使用 Spring 处理程序来映射它们的优点是它从实际应用程序逻辑代码中删除了使用正确代码的繁琐响应构造(它与在这方面的方面):只需抛出正确的异常并完成它。
OTOH，与错误处理代码的距离意味着 1. 如果某事不起作用，可能很难追踪到问题 2. 您需要知道要抛出哪些异常，这不是立即显而易见的，并且需要妥善记录。
关于java - 在 http API 中引发 "bad requests"异常是否是一种好习惯 - 与(Java)最佳实践相矛盾，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/57473175/