作者：小梦茜呦_163 | 来源：互联网 | 2024-12-11 16:05
一位开发者提出疑问：‘关于业务异常的处理方式’，他在V站搜索发现的大多是过时的帖子，因此新开此贴寻求建议。
他提到，在前一家公司，对于如用户名错误等业务异常，通常不使用异常处理机制，而是直接通过返回特定的消息来告知前端。例如，在登录功能中，如果用户名不存在，则直接返回一个错误信息：
1
2
3
4
5
6
7
8
9
10
11
12
13 | public void login(String username, String password) {
User user = db.getUsername(username);
if (user == null) {
// UnifyResponse 是用于封装响应结果的实体类，参数1:状态码，参数2:消息内容
return UnifyResponse.FAIL(400, "用户不存在");
}
} |
前端接收的响应格式如下：
1
2
3
4
5
6 | http status: 200
{
code: 400,
message: "用户名不正确"
} |
而在当前公司，对于类似的业务异常，采用的是抛出异常的方式，然后在全局异常处理器中统一处理这些异常，返回给前端的响应如下：
1
2
3
4
5
6
7
8
9
10
11
12
13 | public void login(String username, String password) {
User user = db.getUsername(username);
if (user == null) {
throw new NotFoundException(400, "用户名不正确");
}
} |
前端接收的响应格式为：
1
2
3
4
5
6
7 | http status: 404
{
code: 400,
message: "用户名不正确"
} |
基于以上两种方法，提出了两个具体的问题：
- 业务逻辑中遇到异常时，是应该直接返回错误信息，还是应该抛出异常并在全局捕获后再返回给前端？
- HTTP状态码的选择上，是应该统一使用200状态码，还是应该根据RESTful规范使用适当的错误代码（如404表示未找到资源，403表示没有权限）？
开发者们普遍认为，遵循RESTful规范使用适当的HTTP状态码可以提高系统的可维护性和用户体验，同时也能更好地与现代Web开发标准接轨。然而，这也需要考虑前端开发者的接受程度和现有系统的设计兼容性。
京公网安备 11010802041100号