go 错误处理设计思考
前段时间准备对线上一个golang系统服务进行内部开源,对代码里面的错误处理进行了一波优化。
优化的几个原因:
- 错误处理信息随意,未分类未定义。看到错误日志不能第一时间定位
- 错误的日志重复,有时候一个错误经过了好几层,每一层都会记录,导致日志混乱
- 错误处理不统一,使用不统一,管理也不统一
优化的解决办法:
- 对错误进行分类,统一定义和使用
- 每一个错误都有冒泡到包的顶层,处理与记日志。使用方只需定义好自己的信息
实施过程
错误分类:函数级,包模块级,系统api级。
函数级别:
还是采用 err != nil 的形式,并且做一个如下的包装。
模块级别
统一返回到对应的goroutine顶层处理
服务对外级别
适当的code和健名的message
底层错误级别
考虑及时panic,暴露有用信息
以下为代码设计:
点击查看代码
package ferrors
import (
"fmt"
"golang.org/x/xerrors"
)
//Errors 新的错误处理方式
type Errors struct {
Code int64
Msg string
}
// Error 输出错误信息
func (e Errors) Error() string {
return fmt.Sprintf("code: %d msg: %s at: %s", e.Code, e.Msg, "错误位置,堆栈信息,可选")
}
// New 创建自定义错误
func New(code int64, str string, arg ...interface{}) *Errors {
if len(arg) > 0 {
str = fmt.Sprintf(str, arg...)
}
return &Errors{Code: code, Msg: str}
}
// newErr 创建通用错误
func newErr(code int64, err error) *Errors {
switch err := err.(type) {
case *Errors:
return err
case nil:
return &Errors{Code: code, Msg: ""}
default:
return &Errors{Code: code, Msg: err.Error()}
}
}
func NewErrNotFound(err error) error {
return newErr(CodeMkNotFound, err)
}
// ErrorEcho example:使用 error wrapping
func ErrorEcho(err error) string {
return fmt.Sprintf("the error %w", err)
}
//ErrorDump example: xerrors 打印堆栈信息
func ErrorDump() {
err := foo1()
fmt.Printf("%v\n", err)
fmt.Printf("%+v\n", err)
}
var myError = xerrors.New("myerror")
func foo() error {
return myError
}
func foo1() error {
return xerrors.Errorf("foo1 : %w", foo())
}
go 错误处理设计思考的更多相关文章
- 用thinkphp进行微信开发的整体设计思考
用thinkphp进行微信开发的整体设计思考 http://www.2cto.com/weixin/201504/388423.html 2015-04-09 0个评论 作者:明 ...
- Atitit. null错误的设计 使用Optional来处理null
Atitit. null错误的设计 使用Optional来处理null 然后,我们再看看null还会引入什么问题. 看看下面这个代码: String address = person.getCount ...
- 2018.8.3 Java中容易犯错误的问题思考与总结
Java容易犯错误的问题思考 float型 float f = 3.4 是否正确 不正确,应该用强制类型转换.如下所示:float f = (float)3.4 或float f = 3.4f 在ja ...
- Java实现本地小数据量缓存尝试与实践&设计思考
话不多说先贴代码 /** * 缓存工具 */ public class ConcurrentHashMapCacheUtils{ /** * 当前缓存个数 */ public static Integ ...
- 深究带PLL的错误复位设计
PLL复位通常犯的错误 或者是像上一篇文章 FPGA知识大梳理(四)FPGA中的复位系统大汇总 中的图一样,也是错误设计.为何呢?看ALTPLL (Phase-Locked Loop) IP Cor ...
- Extjs的架构设计思考,单页面应用 or 多页面?
写在前面:不要认为 EXTJS 高版本就是一个界面改良,在项目中,仍然用 N 张页面,在 N 张页面部署 EXTJS .这种方式不用多讲,效率问题大家都看得出来, EXTJS 是一个集成开发工具,注定 ...
- RESTful API 设计思考
RESTful API 设计思考,内容来源网络加自己的思考 1.RESTful Web API采用面向资源的架构:同一的接口,所以其成员体现为针对同一资源的操作2.SOAP Web API采用RPC风 ...
- 比原链设计思考: 扩展性UTXO模型
用户模型是比原链在最初就需要确定的重要数据结构, 团队的选择还是聚焦在两种典型的模型系统中,Account模型和UTXO模型,和其他大多数区块链设计一样, 选择了模型就决定了协议层的重要实现,两种模型 ...
- 游戏设计思考:对COK的理解和思考
转自:http://www.gameres.com/804983.html 一.前言 发此文的起因是最近加入了一个游戏研究群,受到大家对游戏研究热情的感染,也想将自己对游戏的理解和感悟发出来和大家一起 ...
随机推荐
- 前端规范之Git提交规范(Commitizen)
代码规范是软件开发领域经久不衰的话题,几乎所有工程师在开发过程中都会遇到或思考过这一问题.而随着前端应用的大型化和复杂化,越来越多的前端团队也开始重视代码规范.同样,前段时间,笔者所在的团队也开展了一 ...
- Spring Cloud Gateway 动态修改请求参数解决 # URL 编码错误传参问题
Spring Cloud Gateway 动态修改请求参数解决 # URL 编码错误传参问题 继实现动态修改请求 Body 以及重试带 Body 的请求之后,我们又遇到了一个小问题.最近很多接口,收到 ...
- [源码解析] PyTorch 流水线并行实现 (5)--计算依赖
[源码解析] PyTorch 流水线并行实现 (5)--计算依赖 目录 [源码解析] PyTorch 流水线并行实现 (5)--计算依赖 0x00 摘要 0x01 前文回顾 0x02 计算依赖 0x0 ...
- Superior Scheduler:带你了解FusionInsight MRS的超级调度器
摘要:Superior Scheduler是一个专门为Hadoop YARN分布式资源管理系统设计的调度引擎,是针对企业客户融合资源池,多租户的业务诉求而设计的高性能企业级调度器. 本文分享自华为云社 ...
- bzoj1834 ZJOI2010网络扩容(费用流)
给定一张有向图,每条边都有一个容量C和一个扩容费用W.这里扩容费用是指将容量扩大1所需的费用. 求: 1.在不扩容的情况下,1到N的最大流: 2.将1到N的最大流增加K所需的最小扩容费用. 其中\(n ...
- PAT (Basic Level) Practice (中文)1007 素数对猜想 (20分)
1007 素数对猜想 (20分) 让我们定义dn为:dn = pn+1 − pn,其中pi是第i个素数.显然有d1 = 1,且对于n > 1有dn是偶数."素数对猜想"认 ...
- Windows内核开发-9-32位和64位的区别
Windows内核开发-9-32位和64位的区别 32位的应用程序可以完美再64位的电脑上运行,而32位的内核驱动无法再64位的电脑上运行,或者64位的驱动无法在32位的应用程序上运行.这是为什么呢. ...
- SharkCTF2021 pwn“初见”1
(无内鬼 今日不想学了 水一篇) nc nc nc easyoverflow Intoverflow
- 【UE4 C++】 Config Settings配置文件(.ini)
简介 常见存储路径 \Engine\Config\ \Engine\Saved\Config\ (运行后生成) [ProjectName]\Config\ [ProjectName]\Saved\Co ...
- Scrum Meeting 15
第15次例会报告 日期:2021年06月09日 会议主要内容概述: 开发工作接近尾声,接下来两天重点放在单元测试.调CSS和增加数据集数量上. 一.进度情况 我们采用日报的形式记录每个人的具体进度,链 ...