失败处理
在编写应用的过程中,我们常常面临两种失败情况。一种是与业务流程直接相关的失败,比如用户不存在或订单状态已经改变;另一种则是由意外错误引发的失败,例如网络问题或系统资源溢出。
针对业务相关的失败,我们可以使用 reject
方法主动抛出错误,为客户端提供明确的失败反馈。例如:
通过这种方式,我们能够精确地向客户端传达请求失败的原因,增强系统的健壮性和可靠性。调用者将接收到如下格式的响应:
调用者可以通过 code.success
简易判断请求的成功与否,并通过 fail.code
识别具体的失败类型。这种设计有助于清晰地传达请求状态,便于调用者有效地处理和响应失败情况。
错误代码
在 /src/fail-code.ts
文件中,我们定义了所有可能的错误代码。
每个键都对应一个特定的错误代码,其值是一个函数,返回描述失败原因的字符串。这种设计便于管理和清晰地组织不同的错误代码,并为每个错误代码提供详细的说明。
参数传递
在调用 reject
方法时,可以通过参数调整向客户端发送的错误消息。这允许开发者根据需要灵活定制错误信息。
请记住,该方法仅接受一个参数。若需传递多个参数,请通过返回一个对象来实现,如下所示:
这些参数也会被发送给客户端,以便进行进一步的处理。客户端将接收到如下格式的响应:
业务失败
大多数失败情况源于业务逻辑,例如超过了截止日期或库存不足。对于这些局部的业务失败,我们通常只需告知用户失败的原因。此时,我们可以统一使用 BUSINESS_FAIL
状态码:
意料之外的错误
对于任何未被捕获的错误,客户端将接收到固定的 INTERNAL_SERVER_ERROR
错误码,以防止敏感信息泄露。
用户友好的失败信息
错误消息应向用户解释失败原因,但并非所有消息都足够用户友好。例如,密码长度不足导致的 TYPE_SAFE_ERROR
失败,我们可能不希望直接向用户显示:
而是希望用户看到更友好的提示:
建议这种用户友好的错误消息处理在客户端完成。这样做的好处包括:
- 实现前后端的彻底解耦。
- 简化语言切换功能的实现,无需在客户端和服务器端都进行处理。
- 确保客户端始终负责编写用户友好的失败消息。
详细信息请参考 Milkio Client。