Java抛出异常与catch中的返回响应 [英] Java Throwing exceptions vs returning response in catch

问题描述

我知道很多关于异常处理的讨论，但是我需要一些具体针对我的情况的建议。

I know a lot has been discussed around exception handling, however I need some advice specific to my situation.

目前，我正在使用 Spring MVC 应用程序，使用 Controller-> Services- > DAO 层。服务类主要捕获两种异常： HibernateException 和 IOException 。

I am currently working on a Spring MVC application with Controller->Services->DAO layers. The service classes catch mainly two kinds of exceptions HibernateException and IOException.

HibernateException 因为服务需要执行回滚，如果事务没有成功，并且 IOException ，因为它是一个未经检查的异常，需要被抓住或抛出，我更喜欢第一个选项。

HibernateException because service needs to perform rollback if a transaction did not succeed and IOException since it is an unchecked exception and needs to be caught or thrown and I prefer the first option.

现在，在堆栈中进一步处理这些更好的方法是什么：

Now what would be a better way of handling these further up in the stack :

我应该将控制器的这些异常重新抛出，控制器的
ExceptionHandler 发送HTTP错误代码500

1. 或者在catch块中创建正常的 JSON响应对象，设置 status = failure 和相应的错误消息并将其返回给控制器？

1. Should I rethrow these exceptions to the controller and in the ExceptionHandler of the controller send a HTTP error-code 500
2. Or in the catch block create the normal JSON response object, setting status=failure and the appropriate error message and return this to the Controller?

推荐答案

异常处理转换：

有一句话说，最好的处理方法异常不是处理它！

There is a saying that, best way of handling Exception is not to handle it!

对于 Spring 约定 controller< - > service< - > dao 层，异常处理机制称为 Bubble up 。在 dao 或服务图层中发生任何异常，您应将其弹出到控制器层（通过添加 throws XXXException 在dao和服务层的方法签名中，是最常见的方式）。只有控制器层应该处理异常。

For Spring's convention of controller<->service<->dao layers, Exception handling mechanism is known as Bubble up. Any exception occurs in the dao or service layer, you should pop it up to the controller layer (by adding throws XXXException in dao and service layer's method signature, is the most common way). Only controller layer should handle Exceptions.

这是一个很好的教程，您可以如何使用spring处理REST的异常。

Here is a nice tutorial of how you can handle exceptions for REST with spring.

发送HTTP状态代码500或具有状态的JSON对象：

Send HTTP Status code 500 or JSON object with status:

听起来像是在使用编写API ... Spring MVC 。看，当你编写API时，你应该遵循适当的惯例。在全球范围内，对于内部服务器错误，您发送代码 500 的HTTP响应，这意味着内部服务器错误。

Sounds like you are writing API with Spring MVC. Look, when you are writing API's you should follow the proper conventions. It is Globally accepted that for internal server errors you send HTTP response with code 500, that means internal server errors.

在这种情况下，您不应该发送的原因有多种， JSON 。主要原因之一是您的API客户端的隐含假设。这就是HTTP响应，代码 200 与 JSON 对象意味着每件事情都正常。因此，客户端业务逻辑可能会反映出最终错误的假设。

There are number of causes for what you should not send JSON response in this case. One of the main cause is the implicit assumption of your API client. That is HTTP response with code 200 with a JSON object means every thing went normal. And thus the client side business logic may reflect that assumption which is wrong eventually.

这里您可以看到一些 API 某些知名组织的错误代码约定：

Here you can see some API error code conventions for some well-known organizations:

• twitter


• LinkedIn


• Facebook Graph API

• twitter
• LinkedIn
• Facebook Graph API

这篇关于Java抛出异常与catch中的返回响应的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！