异常处理标准

Question

我正在编写一个API，当然会返回一些响应。有可能是例外。 在任何异常的情况下，有两种响应选项：

1. 回复一些错误消息，让消费者知道发生了什么。

2. 而不是错误消息返回默认响应，不要让 消费者知道如果发生了不好的事情。

我知道这两种方法各有利弊。

我只是想知道，采用哪种方法更好，为什么？

Answer 1

API绝不会让用户想知道为什么他们没有得到预期的响应。

转发给用户的错误应该至少有两种：

• 由于传递给API调用的无效参数而导致的错误。这是用户错误。如果您的API公开HTTP，则预计会出现400错误。

尽管提供的参数正确，但在API服务器上发生的

• （意外）错误。如果您的API公开HTTP，则预计会出现500错误。

对于用户（400）错误，API应提供有关错误的最大详细信息，以便用户可以更正其输入。

对于服务器（500）错误，这取决于您，但更多详细信息，更容易支持的呼叫将回答。由于这可能是一个错误，因此堆栈跟踪对于开发人员来解决问题是一个很大的帮助。

Answer 2

<强> 1。返回一些错误消息作为回应，让消费者知道发生了什么。

您应该尝试扩展Exception类并定义自己的异常代码，然后抛出此自定义异常对象，而不是SQLException或DataAccessExceptions。

稍后您还可以提供基本手册，根据您定义的自定义代码对错误进行故障排除。

向最终用户显示SQL跟踪/异常是一个坏主意，因为它可能会显示有关您的应用程序的一些重要信息，如SQL查询，数据库架构和表名称等。

<强> 2。而不是错误消息返回默认响应，不要让消费者知道如果发生了什么坏事。

这不是一种推荐的方法，因为它会让用户处于对API出现问题以及他们可以采取哪些措施来修复它的神秘状态。