大型项目中,打印 error 就是个字符串,非常难以调试,很痛苦。
我记得之前看到文章说 xerrors 的 error 包含堆栈功能会合到标准库里面,为啥现在还没有合并?
go 未来还会支持 error 中包含堆栈信息这个功能吗?
1 b00tyhunt3r 2021-09-24 09:39:11 +08:00 有啊 具体函数名忘了 你查一下 error package |
![]() | 2 SorcererXW 2021-09-24 09:40:25 +08:00 因为更好的错误处理方案一直没有定论,所以不会把一个临时解决方案合入标准库 |
![]() | 3 masterclock 2021-09-24 10:04:44 +08:00 go 初始的东西,语言本身,核心概念就是凑合 go 后续的提案等等都是绝不凑合,没找到和口味的之前绝不加入新东西 用 zerolog 等 logger, 可以附带 stack trace |
![]() | 4 nanmu42 2021-09-24 10:12:44 +08:00 ![]() 也许可以考虑这样的实现方式,每一层调用者在发现调用的函数返回非空 nil 后,都使用 fmt.Errorf()提供上下文后再向 return 到上一层。 例如: ``` err := client.Ping(ctx).Err() if err != nil { err = fmt.Errorf("redis PING: %w", err) return nil, err } ``` 这样到了最外层(一般是打日志的时候),文本化的 err 会形如:running up: program init: redis PING: network IO timeout 在大部分情况下,我自己感觉这个都比堆栈来得实用。 |
![]() | 5 xuzhzzz 2021-09-24 10:23:55 +08:00 |
![]() | 6 xuzhzzz 2021-09-24 10:26:20 +08:00 ![]() 第一次错误出现的地方 errors.Wrap / errors.Wrapf 中间每一层都直接 return 最外一层打印 |
![]() | 7 KousukeSakurako 2021-09-24 10:35:01 +08:00 在你认为应该被跟踪错误的地方不要直接 return err 可以换成 return fmt.Errorf("error can not xxx: %w", err) |
8 hhaobao 2021-09-24 11:09:55 +08:00 https://goframe.org/pages/viewpage.action?pageId=1114255 goframe 的这个错误处理包还可以, gerror.Wrap 包装栈信息 gerror.WrapCode 还可以带自定义的业务 api code |
![]() | 9 byx 2021-09-24 11:22:06 +08:00 |
![]() | 10 zhuangzhuang1988 2021-09-24 12:17:20 +08:00 大道至简, 你不懂. |
![]() | 11 fgwmlhdkkkw 2021-09-24 18:21:10 +08:00 |
![]() | 12 meiyoumingzi6 2021-09-24 21:28:25 +08:00 5 楼正解 |