通常，我只尝试将异常用于“例外”条件（“有效Java”，第69期）。我个人的解释是： 如果我在代码的特定部分（通常是方法或构造函数）中遇到了无法再给出有意义的答案或结果的条件，则会抛出异常，而调用该代码的人必须对其进行处理。
在HTTP端点的特殊情况下，我总是可以给出有意义的答案-带有状态码的响应。 因此，处理错误请求属于端点方法的常规程序流程，不应引发新的异常。
例如如果找不到资源，则返回资源的端点应该只返回404。在我看来，举一个“ SomethingNotFoundExcetion”（可能由错误处理程序处理并创建404响应）是一种不好的做法
我的问题是：对于依赖于异常来创建特定HTTP响应的错误请求（4xy），使用Spring Boot的错误处理机制是错误的做法。 （对于所有未发现的错误，产生500个错误确实很好）
（我只是在撰写代码回顾，并且不确定是否建议不要将错误处理程序用于“正常” API交互）
回答/评论当前答案 （如果我理解正确） 拥有一个中央错误处理程序比服从良好实践更为重要。一种可行的方法是创建一个自己的中央错误处理程序，该处理程序不依赖于Java异常，而是依赖于自己的错误对象。
答案 0 :(得分：1)
这取决于您的项目，这实际上是意见/建筑决策的问题。我会说-或。
使用特定的Exception然后使用Spring处理程序来映射它们的优点是，它从实际的应用程序逻辑代码中删除了带有正确代码的冗长乏味的响应结构（这与各个方面没有什么不同）尊重）：只要抛出正确的异常并加以处理即可。
OTOH，与错误处理代码的距离意味着1.如果某事不起作用，则可能很难找到问题2.您需要知道要抛出哪些异常，并且这不是立即显而易见的，并且需要有据可查。
答案 1 :(得分：1)
这不是一个坏习惯，而是一个体系结构决策问题。有一个错误处理程序将产生4xx响应并执行一些其他错误处理工作，例如记录日志和/或通过邮件或队列发送通知或（例如在我的项目中）在表中写入错误，可能会很好因此，它们可以由用户使用应用程序的GUI组件进行审核，并且在合理的情况下甚至可以进行编辑和重新提交。它还将错误处理统一为一个代码（代码重用）。但是，如果您真的只需要发送4xx响应而没有其他任何响应，那么它就不会引发异常，只需在您的代码中执行即可。引发异常在性能上是昂贵的，并且不应仅出于引发异常的目的而进行。但是在这种情况下，我的看法是使用Exception / Spring boot错误处理机制