20210512 Errors原则 - ziyouzy/2021blog GitHub Wiki

一、从ee组件出发分析此问题：
1.在ee组件中无法被Unwrap成Event的error：
这类error的地位还不如event，这类error之后唯一的收尾工作只需录入日志
2.在ee组件中可被Unwrap成Event的error:
需要将error传入“Loop1~3业务逻辑”
3.在ee组件中可被Unwrap成非Event的error:
如果发生这种情况，就相当于发生了bug

二、从底层组件出发分析此问题：
1.json的序列化失败
需要装入Event
2.io.EOF
需要装入Event
c.ErrNetClosing
需要装入Event
也就是说此情况根本就不需要考虑是否需要被%v

三、从放入Error管道前进行fmt.Errorf("%v/w")的这一时刻分析此问题：
其实是否需要摧毁内部逻辑，只需去衡量一件事即可，那就是在进行Errors<-fmt.Errorf()操作的这一时刻，参数commentRaw或commentError的其中之一对“系统”来说是否有意义即可

ps:
river-node或river进行Construct方法时失败所返回的error:
会被放入其上层与其对接的Event，而%v/w的问题则适用“三”类型的情况
river-node或river或其他功能模块进行初始化时所发生的错误:
直接记录于log，等同于初始化成功的记录log操作
基于一.3:要明确的是整个代码逻辑硬性规定了只有event才能被Errors<-fmt.Errorf()