标签 Go 下的文章

Go错误处理:错误链使用指南

本文永久链接 – https://tonybai.com/2023/05/14/a-guide-of-using-go-error-chain

0. Go错误处理简要回顾

Go是一种非常强调错误处理的编程语言。在Go中,错误被表示为实现了error接口的类型的值,error接口只有一个方法:

type error interface {
    Error() string
}

这个接口的引入使得Go程序可以以一致和符合惯用法的方式进行错误处理。

在所有编程语言中,错误处理的挑战之一都是能提供足够的错误上下文信息,以帮助开发人员诊断问题,同时又可以避免开发人员淹没在不必要的细节中。在Go中,这一挑战目前是通过使用错误链(error chain)来解决的。

注:Go官方用户调查结果表明,Go社区对Go错误处理机制改进的期望还是很高的。这对Go核心团队而言,依然是一个不小的挑战。好在Go 1.18泛型落地,随着Go泛型的逐渐成熟,更优雅的错误处理方案有可能会在不远的将来浮出水面。

错误链是一种将一个错误包裹在另一个错误中的技术,以提供关于错误的额外的上下文。当错误通过多层代码传播时,这种技术特别有用,每层代码都会为错误信息添加自己的上下文。

不过,最初Go的错误处理机制是不支持错误链的,Go对错误链的支持和完善是在Go 1.13版本中才开始的事情。

众所周知,在Go中,错误处理通常使用if err != nil的惯用法来完成。当一个函数返回一个错误时,调用代码会检查该错误是否为nil。如果错误不是nil,通常会被打印到日志中或返回给调用者。

例如,看下面这个读取文件的函数:

func readFile(filename string) ([]byte, error) {
    data, err := os.ReadFile(filename)
    if err != nil {
        return nil, err
    }
    return data, nil
}

在这段代码中,os.ReadFile()如果读取文件失败,会返回一个错误。如果发生这种情况,readFile函数会将错误返回给它的调用者。Go的这种基本的错误处理机制简单有效好理解,但它也有自己的局限性。其中一个主要的限制是错误信息可能是模糊的。当一个错误在多层代码中传播时,开发人员可能很难确定错误的真实来源和原因。 我们看一下下面这段代码:

func processFile(filename string) error {
    data, err := readFile(filename)
    if err != nil {
        return fmt.Errorf("can not read file: %s", filename)
    }
    // process the file data...
    return nil
}

在这个例子中,如果processFile因readFile失败而返回一个错误,错误信息将只表明该文件无法被读取,它不会提供任何关于造成错误的原因或错误发生地点的准确信息

Go基本错误处理的另一个约束是在处理错误时,错误的上下文可能会丢失。尤其是当一个错误通过多层代码时,某一层可能会忽略收到的错误信息,而是构造自己的错误信息并返回给调用者,这样最初的错误上下文就会在错误的传递过程中丢失了,这不利于问题的快速诊断。

那么,我们如何解决这些限制呢?下面我们就来探讨一下错误链是如何如何帮助Go开发人员解决这些限制问题的。

1. 错误包装(error wrapping)与错误链

为了解决基本错误处理的局限性,Go在1.13版本中提供了Unwrap接口和fmt.Errorf的%w的格式化动词,用于构建可以包裹(wrap)其他错误的错误以及从一个包裹了其他错误的错误中判断是否有某个指定错误,并从中提取错误信息。

fmt.Errorf是最常用的用于包裹错误的函数,它接收一个现有的错误,并将其包装在一个新的错误中,并可以附着更多的错误上下文信息。

例如,改造一下上面的示例代码:

func processFile(filename string) error {
    data, err := readFile(filename)
    if err != nil {
        return fmt.Errorf("failed to read file: %w", err)
    }
    // process the file data...
    return nil
}

在这段代码中,fmt.Errorf通过%w创建了一个新的错误,新错误包裹(wrap)了原来的错误,并附加了一些错误上下文信息(failed to read file)。这个新的错误可以在调用堆栈中传播并提供更多关于这个错误的上下文。

为了从错误链中检索原始错误,Go在errors包中提供了Is、As和Unwrap()函数。Is和As函数用于判定某个error是否存在于错误链中,Unwrap这个函数返回错误链中的下一个直接错误。

下面是一个完整的例子:

func readFile(filename string) ([]byte, error) {
    data, err := os.ReadFile(filename)
    if err != nil {
        return nil, err
    }
    return data, nil
}

func processFile(filename string) error {
    data, err := readFile(filename)
    if err != nil {
        return fmt.Errorf("failed to read file: %w", err)
    }
    fmt.Println(string(data))
    return nil
}

func main() {
    err := processFile("1.txt")
    if err != nil {
        fmt.Println(err)
        fmt.Println(errors.Is(err, os.ErrNotExist))
        err = errors.Unwrap(err)
        fmt.Println(err)
        err = errors.Unwrap(err)
        fmt.Println(err)
        return
    }
}

运行这个程序(前提:1.txt文件并不存在),结果如下:

$go run demo1.go
failed to read file: open 1.txt: no such file or directory
true
open 1.txt: no such file or directory
no such file or directory

该示例中错误的wrap和unwrap关系如下图:

像这种由错误逐个包裹而形成的链式结构(如下图),我们称之为错误链

接下来,我们再来详细说一下Go错误链的使用。

2. Go中错误链的使用

2.1 如何创建错误链

就像前面提到的,我们通过包裹错误来创建错误链

目前Go标准库中提供的用于wrap error的API有fmt.Errorf和errors.Join。fmt.Errorf最常用,在上面的示例中我们演示过了。errors.Join用于将一组errors wrap为一个error。

fmt.Errorf也支持通过多个%w一次打包多个error,下面是一个完整的例子:

func main() {
    err1 := errors.New("error1")
    err2 := errors.New("error2")
    err3 := errors.New("error3")

    err := fmt.Errorf("wrap multiple error: %w, %w, %w", err1, err2, err3)
    fmt.Println(err)
    e, ok := err.(interface{ Unwrap() []error })
    if !ok {
        fmt.Println("not imple Unwrap []error")
        return
    }
    fmt.Println(e.Unwrap())
}

示例运行输出如下:

wrap multiple error: error1, error2, error3
[error1 error2 error3]

我们看到,通过fmt.Errorf一次wrap的多个error在String化后,是在一行输出的。这点与errors.Join的有所不同。下面是用errors.Join一次打包多个error的示例:

func main() {
    err1 := errors.New("error1")
    err2 := errors.New("error2")
    err3 := errors.New("error3")

    err := errors.Join(err1, err2, err3)
    fmt.Println(err)
    errs, ok := err.(interface{ Unwrap() []error })
    if !ok {
        fmt.Println("not imple Unwrap []error")
        return
    }
    fmt.Println(errs.Unwrap())
}

这个示例输出如下:

$go run demo2.go
error1
error2
error3
[error1 error2 error3]

我们看到,通过errors.Join一次wrap的多个error在String化后,每个错误单独占一行。

如果对上面的输出格式都不满意,那么你还可以自定义Error类型,只要至少实现了String() string和Unwrap() error 或Unwrap() []error即可。

2.2 判定某个错误是否在错误链中

前面提到过errors包提供了Is和As函数来判断某个错误是否在错误链中,对于一次wrap多个error值的情况,errors.Is和As也都按预期可用。

2.3 获取错误链中特定错误的上下文信息

有些时候,我们需要从错误链上获取某个特定错误的上下文信息,通过Go标准库可以至少有两种实现方式:

第一种:通过errors.Unwrap函数来逐一unwrap错误链中的错误。

由于不确定错误链上的error个数以及每个error的特征,这种方式十分适合用来获取root cause error,即错误链中最后面的一个error。下面是一个示例:

func rootCause(err error) error {
    for {
        e, ok := err.(interface{ Unwrap() error })
        if !ok {
            return err
        }
        err = e.Unwrap()
        if err == nil {
            return nil
        }
    }
}

func main() {
    err1 := errors.New("error1")

    err2 := fmt.Errorf("2nd err: %w", err1)
    err3 := fmt.Errorf("3rd err: %w", err2)

    fmt.Println(err3) // 3rd err: 2nd err: error1

    fmt.Println(rootCause(err1)) // error1
    fmt.Println(rootCause(err2)) // error1
    fmt.Println(rootCause(err3)) // error1
}

第二种:通过errors.As函数将error chain中特定类型的error提取出来

error.As函数用于判断某个error是否是特定类型的error,如果是则将那个error提取出来,比如:

type MyError struct {
    err string
}

func (e *MyError) Error() string {
    return e.err
}

func main() {
    err1 := &MyError{"temp error"}
    err2 := fmt.Errorf("2nd err: %w", err1)
    err3 := fmt.Errorf("3rd err: %w", err2)

    fmt.Println(err3)

    var e *MyError
    ok := errors.As(err3, &e)
    if ok {
        fmt.Println(e)
        return
    }
}

在这个示例中,我们通过errors.As将错误链err3中的err1提取到e中,后续就可以使用err1这个特定错误的信息了。

3. 小结

错误链是Go中提供信息丰富的错误信息的一项重要技术。通过用额外的上下文包装错误,你可以提供关于错误的更具体的信息,并帮助开发人员更快地诊断出问题。

不过错误链在使用中有一些事项还是要注意的,比如:避免嵌套错误链。嵌套的错误链会使你的代码难以调试,也难以理解错误的根本原因。

结合错误链,通过给错误添加上下文,创建自定义错误类型,并在适当的抽象层次上处理错误,你可以写出简洁、可读和信息丰富的错误处理代码。


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2023年,Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码,关注代码质量并深入理解Go核心技术,并继续加强与星友的互动。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

Go项目组织:在单一repo中管理多个Go module指南

本文永久链接 – https://tonybai.com/2023/05/10/a-guide-of-managing-multiple-go-modules-in-mono-repo

0. 单repo单module管理回顾

众所周知,Go在1.11版本中引入了go module,随着近几年Go module机制的逐渐成熟,它已经被Go团队确定为Go标准的依赖管理与构建方案,原先的GOPATH mode已经被彻底废弃。

在Go module模式下,最常见的Go项目组织方式就是一个repo(代码仓库)对应一个Go module。repo的根路径中放置go.mod文件,repo的根路径也是module root directory。该Go module下的package的导入路径则由go.mod中的module path以及该package相对于module root directory的路径共同构成。

以“example.com/go”这一module path为例,如果某个package存放在foo/bar下,那么bar下的package的导入路径就是“example.com/go/foo/bar”;如果是v2版本,那么导入路径为“example.com/go/v2/foo/bar”。

在一个repo对应一个Go module的策略下,Go module的版本管理和发布也相对容易,通常我们采用分支方式来进行major号升级(如下图),通过tag来进行版本发布

上图是单repo单module的分支管理方案,两种方案均可。

左侧的方案中:master分支承载v0-v1,每升级一个major号,建立一个vN分支,default分支指向最高major号的分支,方便开发者clone repo时直接拿到最新的代码。

注:左侧方案有一个问题,那就是一旦default分支执行最高major号分支vN,那么你如果要go get master分支的最近更新,需要显式指定master分支,比如: go get example.com/go/foo/bar@master。使用latest或不加任何分支名都无法获取到master上的最新更新。

右侧的方案也是建立vN分支,但不同的是,该方案会将master分支作为active开发分支,也是默认分支并定期将稳定后的feature同步到最高major号分支,这也是我个人比较喜欢的方式。前不久刚刚被官宣为redis官方Go客户端的go-redis采用的就是这个方案(下面是go-redis的vN分支情况):

注:在单一repo中管理一个go module的方法十分成熟了。我在专栏《Go语言第一课》的06和07讲对此做了系统的讲解,感兴趣的小伙伴可以去阅读一下。

有了单repo单module的项目组织方式,就会有单repo多module的组织方式,比如著名的etcd项目,就是在一个repo中管理多个go module的典型例子。

那么为什么要在一个repo中管理多个go module呢?我们继续往下看。

1. 为什么要在一个repo中管理多个Go module

其实这个问题的本质是monorepo与multiple repo之间的“战争”。那么上述问题也就变成了一个monorepo与multiple repo的优劣对比。我个人从未真正使用过monorepo这种所有项目代码都放在一个单一仓库中的组织形式,不过从网上的公开资料来看,monorepo有如下的一些优点:

  • 容易看到

如果你正在做一个调用其他微服务的微服务,你可以看一下代码,了解它是如何工作的,并确定bug是来自你自己的代码还是其他团队的微服务。

  • 代码共享

团队为微服务重复编写代码会产生额外的工作开销。有了monorepo,团队可以更容易地分享代码。

  • 改进协作

有了monorepo,就更容易在各团队之间实现代码和工具的标准化。

  • 标准化

单一代码仓库使得跨团队的代码和工具的标准化更加容易。

  • 可发现性

有了monorepo,更容易找到你需要的代码。

  • 发布管理

单一版本使我们更容易地管理跨多个服务的发布。

  • 更容易重构

重构代码在单版本中更容易,因为所有的代码都在一个地方。

当然,使用单一代码仓库也有一些缺点,这些缺点也足以让很多组织和开发团队对其望而却步:

  • 增加仓库的大小

一个单库通常会比只包含一个项目的版本库大。这可能会导致更长的构建时间和更多的磁盘空间使用。

  • 增加复杂性

单一代码仓库的管理比只包含一个项目的版本库更复杂。这是因为有更多的代码需要跟踪和管理。

  • 增加冲突的风险

当多个开发者在单一仓库中处理相同的代码时,会有更大的冲突风险。这是因为开发人员可能在同一个代码的不同版本上工作。

  • 不能限制访问

monorepo不允许有选择的分享。

  • 陡峭的学习曲线

当新的开发者开始与已经有monorepo的组织合作时,他们通常需要足够长的时间来适应所有紧密耦合的依赖关系。

总的来说,使用monorepo既有优点也有缺点,是否使用monorepo最终还是要取决于项目和团队的具体需求。

不过,monorepo下的多module是实际存在的,并且Google内部就是如此,显然go module也一定要对此做很好的支持的,下面我们就来看看go是如何支持mono repo下的多个go module的。

我们先来看看mono repo下各个go module的导入路径的确定。

2. monorepo中各个go module下的package的导入路径

在前面回顾单repo单module的项目组织方式下,module下的package的导入路径为:module path+package在module root directory下的相对路径。那么monorepo中各个go module下的package的导入路径又是什么呢?

首先monorepo下的各个go module的module root路径并非monorepo的root路径,以下面的结构举例;

example.com
└── go/
    ├── mqtt/
    │   ├── bar/
    │   │   └── go.mod
    │   └── foo/
    │       └── go.mod
    └── vehicle/
        ├── baz/
        │   └── go.mod
        └── zoo/
            └── go.mod

我们看到在example.com这个顶层目录下并没有go module,go modules分布在example.com下的各个子目录中。以mqtt/bar下的go module为例,它的module path应该为repo根路径+bar的相对路径,即example.com/go/mqtt/bar,这样bar下面的package pkg1,它的导入路径就为example.com/go/mqtt/bar/pkg1,如果bar这个go module升级到v2版本,则pkg1的导入路径就会变为example.com/go/mqtt/bar/v2/pkg1。其余的go module下的packge的导入路径以此类推。

3. monorepo下各个go module的版本发布

在单repo单module下,我们通过打vx.y.z标签的方式发布module,但是在monorepo多module下,再在repo上针对repo打整体的、诸如v1.0.1这样的标签就没有太大意义了(当然为了整体管理的需要,依然可以打整体标签,比如像etcd那样打v3.5.8),并且对于monorepo下的多个go module而言,go get也不会识别这种整体标签,那么我们该如何发布monorepo下的go module呢?

其实也很简单,我们为module单独打标签来发布。以上面的example.com/go/mqtt/bar这个module为例,如果我们要为其发布v1.0.0版本,我们需要为example.com这个repo打上tag:go/mqtt/bar/v1.0.0;如果它要发布v1.1.0版本了,我们则需为example.com这个repo打上tag:go/mqtt/bar/v1.1.0。也就是说要发布哪个module,就用module相对于monorepo根的相对路径+版本号作为tag号

4. monorepo下各个go module的major版本变更

了解了上述monorepo下各个go module的版本发布方式后,我们就可以将monorepo下的每个go module像单repo单module那样单独对待了!以example.com/go/mqtt/bar为例,当major版本变更时,我们可以建立类似go/mqtt/bar/v1分支,然后将master分支的go.mod中的module path改为example.com/go/mqtt/bar/v2,这样我们就可以在go/mqtt/bar/v1分支继续维护v1版本的bar module,并打tag:go/mqtt/bar/v1.x.y;在master分支维护v2版本的bar module,并打tag:go/mqtt/bar/v2.x.y。

当然go还支持另外一种major版本的维护方式,那就是通过目录隔离。当major版本要升级为v2时,我们可以在go/mqtt/bar下面建立v2目录(像v2这类目录被称为major version subdirectories),然后在v2目录下维护major为v2的版本,这种方式下你就无需建立vN分支了,可以在master上通过目录隔离的方式同时维护多个major版本。发布时,同样打go/mqtt/bar/v2.x.y标签。这种方式一个最大的好处就是与GOPATH mode可以“无缝衔接”,因为GOPATH mode下,go工具链就是通过路径查找package的。

不过这种major version subdirectories的方式并不常用,即便在开源项目中也是比较少见的。

5. 小结

本文介绍了go module的基础概念,回顾了单repo单module的包管理方法,包括版本发布、major号升级等。接下来,我们介绍了monorepo下管理多个go module的方案,除了在打tag时要注意带上相对路径外,monorepo下module的包管理方法与单repo单module本质上是一致的。

6. 参考资料

  • REPO STYLE WARS: MONO VS MULTI – https://gigamonkeys.com/mono-vs-multi/
  • Mono Repo vs Multi Repo: Deep Dive Into The Neverending Debate – https://speakerdeck.com/lemiorhan/mono-repo-vs-multi-repo-deep-dive-into-the-neverending-debate

“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2023年,Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码,关注代码质量并深入理解Go核心技术,并继续加强与星友的互动。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats