我已经使用Jersey 1.9返回json实现了REST API，直到现在我没有做任何明确的错误处理，并且框架似乎很好地处理它。
现在我打算创建一个＆＃34;应用程序＆＃34;更好的错误处理框架，我试图寻找最佳实践，但没有找到任何
泽西岛文件： https://jersey.java.net/nonav/documentation/1.9/user-guide.html#d4e443
很少在互联网上搜索： http://www.codingpedia.org/ama/error-handling-in-rest-api-with-jersey/
但我不喜欢这个，因为我们只是捕捉所有异常格式化和重新抛出，我没有看到很多价值。
http://howtodoinjava.com/jersey/jax-rs-jersey-custom-exceptions-handling-with-exceptionmapper/ 我假设unhandeled异常已被框架作为500响应代码处理，所以不要看上面的例子。
此外，我还阅读了很多关于不同方法的讨论，其中即使错误条件以200响应发送，但其空白且很少人发送显式代码，似乎没有＆＃34;标准＆＃34;这导致我提出这个问题，寻求专家＆＃34;
的最佳实践答案 0 :(得分：5)
与最终用户沟通错误是API设计中非常重要的一部分。我建议使用JAX-RS ExceptionMapper机制轻松映射异常以清除错误消息。
我喜欢做的是将所有可以退出服务的例外分组。
这些例外是100％由用户输入引起的，并且服务可以做 nothing 以避免它们。
示例：
它们应该以4XX错误代码的形式返回，并带有明确说明问题原因并可能暗示解决方案的消息。
这些例外是100％由应用程序的当前状态引起的，客户端无法做任何事情来避免它们。
示例：
它们应作为5XX错误代码返回，并显示一条消息，说明服务存在问题，客户端应稍后重试。这些是严重的问题，需要迅速解决。
随着您的应用程序的成熟，您很可能会找到避免诉诸这些错误的方法。例如。在数据库不可用时，通过回退到基于缓存的只读模式。
应在您的应用程序逻辑中处理所有其他异常。如果不需要将它们传达给最终用户，则它们不应该有ExceptionMapper，也不应该到达Jersey层。