逻辑错误和系统错误的错误信息应该通过什么样子的方式返回

[Luoxin]

我个人想法是觉得，不管是业务错误还是逻辑错误都应该是 error 返回，至于这个错误是逻辑错误还是业务错误，是根据 error 的类型判断的。
我觉得不管是什么错误，最终都应该是错误，所谓就应该按照统一的 error 路径返回，而不是一部分错误通过 error 返回，一部分错误通过 response 返回。如果说一个 response 里面除了 error 之外还需要返回一些和 error 相关的信息，我觉得觉得是可以既然返回 error 又返回 response 的。无论是在接口请求上还是单纯的函数调用上

[YangruiEmma]

很好的问题，从业务开发角度，无论是rpc访问的错误还是业务错误都返回error体验会更好，但需要有所区分（监控维度），如果是Thrift的话，对于业务错误建议定义 Thrift Exception，这样针对业务错误可以直接返回特定的error。

[Hchenn]

首先，错误处理没有唯一标准，怎么做都可以，适合自己的是最好的。

其次，个人观点：业务错误和网络错误推荐分开。

主要是一个分工问题，业务大多不需要关心网络错误，网络错误由框架来解决，这样形成良好的分工，而合并返回错误违背了这一理念。
每个错误都要由框架和业务进行双重判断，反而增加了复杂度，业务也不能更专注的处理自身错误。

另外列举几个方面：

1. 协议处理：一些协议如果收到 error, 会直接 return，这样就没办法在处理 error 时同时获得 response。而发生网络错误时一定没有 response，如果业务错误写在 response 的话，可以保证在所有情况下都能拿到全量信息。

2. 调用重试：网络错误大多是可以重试的，但业务错误需要由业务来决定是否能重试。简并的 error 难以快速判断能否重试。而如果可以区分业务错误和网络错误，那么在发生网络错误时可以由框架快速的进行重试。

3. 服务治理：分开返回错误有助于区分埋点，运维分工。如果监控到大量网络错误，可以快速的定位到机器问题(回滚可能解决不了)，而业务错误则可以定位到代码逻辑 bug 上(回滚可以解决)

以上，欢迎讨论 ～

[Luoxin]

我同意任何一种做法都是有合理的方面的，不同的场景下的设计肯定会针对性的选择，所以我现在这里讨论的重点不是方案的对错，而是方案的可行性、优劣势这些。

业务想要表达的完整信息的。如果是通过 error + response 来处理的话，对于业务来说就是要同时处理 error 和 response 了。
但是这个只是对于通信上而言的，对于处理数据的人而言，可以在框架层面上转换一下，比如协议上定义response的保留字段之类的，通过 客户端的框架，把response内表达业务错误的部分通过error返回给客户端框架的调用方，这样对于客户端调用者来说就是始终通过 error 处理错误，而对于运维监控来说，依旧是通过系统错误来监控，这样就不必让调用者去为了 error 和 response 分别做处理了。
当然，出了这些还有一个考虑，并非每一个错误都是需要做处理之后才能给出去。在微服务下，会有相当于的服务间调用，在多层级的调用下，如果出现了一个错误，可能作为一个中间的服务不一定需要处理而是可以直接给出去的。基于这种条件下的场景，如果直接给了error，中间服务可以直接返回 error 而不需要处理完 response 之后才写回到自己需要给出去的 response 里。

[dongpoge]

这个问题，还是我在群里抛出的，因为实际场景中遇到这样的问题。
比如我调一个商家平台接口，去同步平台商品的库存。
我下游OMS 系统把库存的数量改成 -1 （负数），但是平台不支持，返回库存不允许为负数
开始我是直接 error 返回：
errors.New("库存数量不小于0")

但是客户端接收到的数据是：remote or network error: internal exception: rpc error: code = 13 desc = biz error: 库存数量不小于0
如果把 前面的remote or network error: int**** 英文反馈给用户，不太友好，去截取 后面“库存数量不小于0”的中文，又不太合理

所以这种情况下，只能 还是通过 response 返回，response 中带 一些业务状态 如：code:0 是成功，code:-1或者其他编码是失败，并带上失败的错误信息如：msg:"库存数量不小于0"
这样就能满足业务的需求
如果是 网络错误，或者业务逻辑错误，可以直接返回error，毕竟是系统问题，不是业务问题

以上是我的见解。

[xieyuschen]

但是客户端接收到的数据是：remote or network error: internal exception: rpc error: code = 13 desc = biz error: 库存数量不小于0
如果把 前面的remote or network error: int**** 英文反馈给用户，不太友好，去截取 后面“库存数量不小于0”的中文，又不太合理。

请问不合理的地方在哪里，我认为如果把业务逻辑的error wrap一下，就可以很快的做到校验一个错误是业务错误还是网络错误。这样就可以免去校验response内的状态码，简化步骤。

Regards

[Luoxin]

我同意楼上的在网络传输层上对 response 和 error 进行区分的传递数据，但是我认为在框架层面需要做一层转换与处理。比如楼上的例子，我写了如下的伪代码

• 自定义一个 error 类型并实现 error 的接口

  type Err struct {
      Code int
      Msg  string
  }
  
  func (e Err) Error() string {
      return e.Msg
  }
  
  func CreateError(code int, msg string) error {
      return &Err{
          Code: code,
          Msg:  msg,
      }
  }

• 服务端的使用

  type DecStoreReq struct {
  }
  
  type DecStoreRsp struct {
  }
  
  func DecStore() (DecStoreRsp, error) {
      // xxx 前置逻辑
      return DecStoreRsp{}, CreateError(111, "库存数量不小于0")
      // xxx 非 error 逻辑 
  }

• 网络层传输的内容

  {
      "code": 111,
      "msg": "库存数量不小于0"
      //  其他数据
  }

• 客户端使用

  // xxx 其他逻辑
  resp, err := DecStore(DecStoreReq{})
  if err != nil {
      log.Errorf("err:%v", err)
      return err
  }
  // xxx 其他逻辑

  基于上述的样例，客户端依旧是根据 error 来处理数据，而服务端要做的依旧是返回一个错误，其余的应该交由框架去处理，而非由使用框架的人去处理。

以上是我的见解。

[YangruiEmma]

@Luoxin 其实内部有一个与你写的类似的方案，但因为和thrift的体验不一样，对内部用户需要两套规范，所以之前未落实。

对pb的自定义异常方案考虑是这样的，增加 BizStatusError 提供用户创建自定义异常：

type BizStatusError struct {
   msg  string
   code int32
}

func NewStatusError(statusCode int32, msg string) *BizStatusError {
   return &BizStatusError{code: statusCode, msg: msg}
}

func (e *BizStatusError) StatusCode() int32 {
   return e.code
}

func (e *BizStatusError) Error() string {
   return fmt.Sprintf("code=%s, msg=%s", e.code, e.msg)
}

func IsBizStatusError(err error) bool {
   _, ok := err.(*BizStatusError)
   return ok
}

服务端用户在 Handler 中通过 NewStatusError 构造 BizStatusError 返回 err。调用端判断是用户自定义异常，构造 BizStatusError 返回给调用端用户。

@Luoxin 你觉得是否OK

[Luoxin]

这个是我的想法。

我是觉得对于框架使用者来说没有必要去关心底层到底是系统错误还是业务错误，只需要需要做特殊处理的错误处理了，其余的直接给上游就好了。

[YangruiEmma]

补充了自定义异常的 Proposal #511， @Luoxin ，你看下是否可以解决你的问题

[Luoxin]

根据Issues的描述是可以解决我的问题的

[li-jin-gou]

• 自定义一场使用文档 https://www.cloudwego.io/docs/kitex/tutorials/advanced-feature/error_handler/