...我..换了个 IP...

@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

这看起来像极了我们公司。虽然不是华为，只是一般的民营小公司。但是，老板就是想我们天天加班。经常 896。基本一周，3-4 天。完全不明白为什么，可能是听说业内公司都这么玩命，老板也是这么想。工资没一线，加班倒是不少

其实，前后端的接口可以采用 restful api 设计。但是，服务端接口采用 get/post 比较好。然后就是响应状态码就 200。URL 路径设计可以参考 restful 设计。微信好像就是这么干

没感觉完爆，但是用了 3 年多，除了打游戏之外，基本没碰过鼠标了，甚至想全部直接键盘操作

妈蛋，我的 15 款，天才吧居然不肯帮我换

没贷款就不难受。

wi-1000x。骑车的时候，那个风噪猛的耳朵都快聋了。。

@resouer #9 等 V3，感觉新版本有看头。目前采用的是 env 注入模板。还能用着先。但是，管理起来太麻烦了。 观望下半年和服务

好多啊。试试抽奖

我觉得这东西很好用啊，对于很多开发人员，他们根本不关心服务部署在哪，配置要怎么写。 用 helm 就可以随时调整配置文件，定义几套模板就好了。不必下发到各项目中，集中管理部署模版