java WebApplicationException 与响应
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/13359396/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
WebApplicationException vs Response
提问by Mickael Marrache
Among all the possibilities to return a response to the client in a RESTservice, I've seen two possibilities that look equivalent: throwing a WebApplicationException(possibly using a Responseinstance) or returning a Responseinstance.
在REST服务中向客户端返回响应的所有可能性中，我见过两种看起来等效的可能性：抛出WebApplicationException（可能使用Response实例）或返回Response实例。
Why to use one possibility over the other since the result is the same? Is this related to the RESTframework used that may be configured to react differently between exceptions and regular responses?
为什么要使用一种可能性而不是另一种，因为结果是相同的？这是否与所使用的REST框架有关，该框架可能被配置为在异常和常规响应之间做出不同的反应？
回答by Bogdan
Why to use one possibility over the other since the result is the same?
为什么要使用一种可能性而不是另一种，因为结果是相同的？
Maybe because as a (Java) programmer you are accustomed with throwing exceptions when particular rules of the application are broken? Convert some string to a number and you might get a NumberFormatException, use a wrong index in an array and you get an ArrayIndexOutOfBoundsException, acces something you are not allowed to and get a SecurityExceptionetc. You are used to throwing exceptions when the "regular response" can't be created (be it from wrong input or some processing error).
也许是因为作为（Java）程序员，您习惯于在应用程序的特定规则被破坏时抛出异常？将一些字符串转换为数字，你可能会得到一个NumberFormatException，在数组中使用错误的索引，你会得到一个ArrayIndexOutOfBoundsException，访问你不允许的东西并得到一个SecurityException等等。当“常规响应”可以时，你习惯于抛出异常' t 被创建（无论是由于错误的输入还是某些处理错误）。
When you can't return the regular response, you must return an error response to the client. You can do that with either throwing the exception or building the response by hand. It's the same thing for your client, but it's not the same thing for your server side code.
当无法返回常规响应时，必须向客户端返回错误响应。您可以通过抛出异常或手动构建响应来做到这一点。这对您的客户端来说是一样的，但对您的服务器端代码来说是不一样的。
Throwing the exception makes your code cleaner, easier to reason about and thus easier to understand. The idea is to subclass the WebApplicationExceptionand create your own meaningful exceptions out of it (e.g ProductNotFoundException extends WebApplicationException { ... }, AccessDeniedException extends WebApplicationException { ... }or reusing exceptions with an exception mapper).
抛出异常使您的代码更清晰、更易于推理并因此更易于理解。这个想法是子类化WebApplicationException并从中创建您自己的有意义的异常（例如ProductNotFoundException extends WebApplicationException { ... }，AccessDeniedException extends WebApplicationException { ... }或使用异常映射器重用异常）。
It's then cleaner to throw new ProductNotFoundException()or throw new AccessDeniedException()and let the framework handle it instead of building a Responseevery time and later follow the details used to build it to figure out what's happening in that section of code.
然后更清晰地throw new ProductNotFoundException()orthrow new AccessDeniedException()并让框架处理它而不是Response每次都构建一个，然后按照用于构建它的细节来找出该部分代码中发生的事情。
