WebApplicationException与Response [英] WebApplicationException vs Response

问题描述

在 REST 服务中向客户端返回响应的所有可能性中，我看到两种看似相同的可能性：抛出 WebApplicationException （可能使用 Response 实例）或返回 Response 实例。

Among all the possibilities to return a response to the client in a REST service, I've seen two possibilities that look equivalent: throwing a WebApplicationException (possibly using a Response instance) or returning a Response instance.

为什么使用一种可能性而不是另一种可能性，因为结果相同？这与使用的 REST 框架有关，可以配置为在异常和常规响应之间做出不同反应吗？

Why to use one possibility over the other since the result is the same? Is this related to the REST framework used that may be configured to react differently between exceptions and regular responses?

推荐答案

为什么使用一种可能性，因为结果是相同的？

Why to use one possibility over the other since the result is the same?

也许是因为作为（Java）程序员，您习惯于在应用程序的特定规则被破坏时抛出异常？将一些字符串转换为数字，您可能会得到 NumberFormatException ，在数组中使用错误的索引，并得到 ArrayIndexOutOfBoundsException ，访问不允许的内容并获得 SecurityException 等。当无法创建常规响应时，您习惯于抛出异常（是错误的输入或一些处理错误）。

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 SecurityException etc. You are used to throwing exceptions when the "regular response" can't be created (be it from wrong input or some processing error).

如果无法返回常规响应，则必须向客户端返回错误响应。您可以通过抛出异常或手动构建响应来实现此目的。这对你的客户来说是一回事，但对你的服务器端代码却不一样。

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.

抛出异常使你的代码更清晰，更容易推理因此更容易理解。我们的想法是继承 WebApplicationException 并从中创建自己有意义的异常（例如 ProductNotFoundException扩展WebApplicationException {...} ， AccessDeniedException扩展WebApplicationException {...} 或使用异常映射器）。

Throwing the exception makes your code cleaner, easier to reason about and thus easier to understand. The idea is to subclass the WebApplicationException and create your own meaningful exceptions out of it (e.g ProductNotFoundException extends WebApplicationException { ... }, AccessDeniedException extends WebApplicationException { ... } or reusing exceptions with an exception mapper).

然后更清洁到抛出新的ProductNotFoundException（）或抛出新的AccessDeniedException （）让框架处理它而不是构建 响应 每次都会按照用于构建它的详细信息来确定该部分代码中发生的情况。

It's then cleaner to throw new ProductNotFoundException() or throw new AccessDeniedException() and let the framework handle it instead of building a Response every time and later follow the details used to build it to figure out what's happening in that section of code.

这篇关于WebApplicationException与Response的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！