首页   注册   登录

YzSama

V2EX 第 150015 号会员,加入于 2015-12-04 18:57:52 +08:00
今日活跃度排名 1093
YzSama 最近回复了
@huangdaxian #37 😂...
@huangdaxian

封装自定义异常初始化的时候,默认生成。

errors 一般没有多个 error 的存在。

主要是方便后面拓展的时候,客户端不用从 JsonObject 改成 JsonArray。 直接就是用 JsonArray。哈哈
@huangdaxian #32

errors 可以理解具体错误的行为表现。

if(Objects.isNull(token)){
// result 就是 Errors 的体现错误的信息
throws new NotFoundException(ErrorResult.TOKEN_IS_NULL);
}

所以,增加了 NotFoundException(ErrorResult errorResult) ,来体现 业务主要错误的具体信息。

所有自定义异常都是继承 RuntimeException。
对了,我认为异常来控制流程 这一边

因为,我认为流程一旦出错,分两种,可执行 和 不可执行。

可执行,是即使出错了,也无所谓。

不可执行,是一旦数据校验不正确,不可能走下去,应该往外抛。

正常流程,是啥事都没有,这就是正确的并且是按照 研发人员设计的流程走下去的。

如果,全局异常处理的设计去考虑性能问题,我觉得对,也不对。你想想,你用的大部分第三方依赖库,它们不也往外抛异常吗?
我的做法是

1. 全局定义统一异常处理并封装异常信息。
2. 使用 HttpStatus 来做 顶层异常类,例如 401 无权限、400 参数错误或其他、404 资源找不到。包装的时候,直接就包装这类异常。
3. 业务异常里,使用 Code、Message 来处理。

例如:

```json

{
"status": 401,
"error": "Unauthorized",
"message": "用户未登录",
"code": 4001,
"path": "/example/example-xjaldkskskal",
"exception": "com.example.exception.UserNotLoginException",
"errors": [
{
"code": 20009,
"message": "token 为空"
}
],
"timestamp": 1556536629108
}

```

errors 是具体的业务错误信息。errors 包含多个 error。

我们采用了 Restful api 设计,所以使用 httpstatus 来做顶层的异常类,为了更好的针对业务异常进一步的处理和展现,就加了一个 errors。。 只有两层。

个人理解和想法。
想了解,业务系统和 ELK 对接相关实战和优化方案。XD
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1042 人在线   最高记录 5043   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.3 · 8ms · UTC 23:17 · PVG 07:17 · LAX 16:17 · JFK 19:17
♥ Do have faith in what you're doing.