标签 Golang 下的文章

Go 1.12中值得关注的几个变化

Go team如期在2月末发布了Go 1.12版本。从Go 1.12的Release Notes粗略来看,这个版本相较于之前增加了go modules机制WebAssembly支持Go 1.11,变化略“小”。这也给下一个Go 1.13版本预留了足够的“惊喜”空间:)。从目前的plan来看,Go 1.13很可能落地的包括:Go2的几个proposals:Go 2 number literals, error valuessigned shift counts等,以及优化版Escape Analysis等。

言归正传,我们来看看Go 1.12版本中值得我们关注的几个变化。

一. Go 1.12的可移植性

Go 1.12一如既往的保持了Go1兼容性规范,使用Go 1.12编译以往编写的遗留代码,理论上都可以编译通过并正常运行起来。这是很难得的,尤其是在”Go2″有关proposal逐步落地的“时间节点”,想必Go team为了保持Go1付出了不少额外的努力。

Go语言具有超强的可移植性。在Go 1.12中,Go又增加了对aix/ppc64、windows/arm的支持,我们可以在运行于树莓派3的Windows 10 IoT Core上运行Go程序了。

但是对于一些较老的平台系统,Go也不想背上较重的包袱。Go也在逐渐“放弃”一些老版本的系统,比如Go 1.12是最后一个支持macOS 10.10、FreeBSD 10.x的版本。在我的一台Mac 10.9.2的老机器上运行go 1.12将会得到下面错误:

$./go version
dyld: Symbol not found: _unlinkat
  Referenced from: /Users/tony/.bin/go1.12/bin/./go
  Expected in: flat namespace

[1]    2403 trace trap  ./go version

二. Go modules机制的优化

1. GO111MODULE=on时,获取go module不再显式需要go.mod

用过Go 1.11 go module机制的童鞋可能都遇到过这个问题,那就是在GO111MODULE=on的情况下(非GOPATH路径),我要go get某个package时,如果compiler没有在适当位置找到go.mod,就会提示如下错误:

//go 1.11.2

# go get github.com/bigwhite/gocmpp
go: cannot find main module; see 'go help modules'

或

# go get github.com/bigwhite/gocmpp
go: cannot determine module path for source directory /Users/tony/test/go (outside GOPATH, no import comments)

这显然非常不方便。为了go get 一个package,我还需要显式地创建一个go.mod文件。在Go 1.12版本中,这个问题被优化掉了。

//go 1.12

# go get github.com/bigwhite/gocmpp
go: finding github.com/bigwhite/gocmpp latest
go: finding golang.org/x/text/encoding/unicode latest
go: finding golang.org/x/text/transform latest
go: finding golang.org/x/text/encoding/simplifiedchinese latest
go: finding golang.org/x/text/encoding latest
go: downloading golang.org/x/text v0.3.0
go: extracting golang.org/x/text v0.3.0

其他在go 1.11.x中对go.mod显式依赖的命令,诸如go list、go mod download也在Go 1.12版本中和go get一样不再显式依赖go.mod。

并且在Go 1.12中go module的下载、解压操作支持并发进行,前提是go module的Cache路径:$GOPATH/pkg/mod必须在一个支持file locking的文件系统中。

2. go.mod中增加go指示字段(go directive)

go 1.12版本在go.mod文件中增加了一个go version的指示字段,用于指示该module内源码所使用的 go版本。使用go 1.12创建的go.mod类似下面这样:

# go mod init github.com/bigwhite/test
go: creating new go.mod: module github.com/bigwhite/test
# cat go.mod
module github.com/bigwhite/test

go 1.12

按照release notes中的说法,如果go.mod中go指示器指示的版本高于你使用的go tool链版本,那么go也会尝试继续编译。如果编译成功了,那也是ok的。但是如果编译失败,那么会提示:module编译需要更新版本的go tool链。

我们使用go 1.11.4版本go compiler编译下面的上面github.com/bigwhite/test module的代码:

// main.go

package main

import (
    "fmt"
)

func main() {
    fmt.Println("go world")
}

# go build main.go
# ./main
go world

我们看到,虽然go tool chain版本是1.11.4,低于go.mod中的go 1.12,但go 1.11.4仍然尝试继续编译代码,并且顺利通过。

如果我们将代码“故意”修改为下面这样:

//main.go

package main

import (
        "fmt"
)

func main() {
        fmt.Printl("go world") // 这里我们故意将Println写成Printl
}

再用go 1.11.4编译这段代码:

# go build main.go
# command-line-arguments
./main.go:8:2: undefined: fmt.Printl
note: module requires Go 1.12

我们看到go 1.11.4 compiler提示“需要go 1.12″版本编译器。从这里我们看出,我们可以使用go指示器用作module最低version约束的标识。在没有go指示器时,我们只能在文档上显式增加这种约束的描述。

不过,这里有一个小插曲,那就是这种不管go.mod中go版本号是多少,仍然尝试继续编译的机制仅适用于go 1.11.4以及后续高版本。从引入go module的go 1.11到go 1.11.3目前都还不支持这种机制,如果用go 1.11.3尝试编译以下上面的代码,会得到如下结果:

# go build main.go
go build command-line-arguments: module requires Go 1.12

go 1.11.3不会继续尝试编译,而是在对比当前go tool chain版本与go.mod中go指示器的version后,给出了错误的提示并退出。

如果非要使用低于go 1.11.4版本的编译器去编译的话,我们可以使用go 1.12工具链的go mod edit -go命令来修改一下go.mod中的版本为go 1.11。然后再用go 1.11.4以下的版本去编译:

# go mod edit -go=1.11
# cat go.mod
module github.com/bigwhite/test

go 1.11

# go build main.go  //使用go 1.11.3编译器

这样,我们就可用go 1.11~go 1.11.3正常编译源码了。

三. 对binary-only package的最后支持

我在2015的一篇文章 《理解Golang包导入》中提及到Go的编译对源码的依赖性。对于开源工程中的包,这完全不是问题。但是对于一些商业公司而言,源码是公司资产,是不能作为交付物提供给买方的。为此,Go team在Go 1.7中增加了对binary-only package的机制。

所谓”binary-only package”就是允许开发人员发布不包含源码的二进制形式的package,并且可直接基于该二进制package进行编译。比如下面这个例子:

// 创建二进制package

# cat $GOPATH/src/github.com/bigwhite/foo.go
package foo

import "fmt"

func HelloGo() {
    fmt.Println("Hello,Go")
}

# go build -o  $GOPATH/pkg/linux_amd64/github.com/bigwhite/foo.a

# ls $GOPATH/pkg/linux_amd64/github.com/bigwhite/foo.a
/root/.go/pkg/linux_amd64/github.com/bigwhite/foo.a

# mkdir temp
# mv foo.go temp

# touch foo.go

# cat foo.go

//go:binary-only-package

package foo

import "fmt"

# cd $GOPATH

# zip -r foo-binary.zip src/github.com/bigwhite/foo/foo.go pkg/linux_amd64/github.com/bigwhite/foo.a
updating: pkg/linux_amd64/github.com/bigwhite/foo.a (deflated 42%)
  adding: src/github.com/bigwhite/foo/foo.go (deflated 11%)

我们将foo-binary.zip发布到目标机器上后,进行如下操作:

# unzip foo-binary.zip -d $GOPATH/
Archive:  foo-binary.zip
  inflating: /root/.go/pkg/linux_amd64/github.com/bigwhite/foo.a
  inflating: /root/.go/src/github.com/bigwhite/foo/foo.go

接下来,我们就基于二进制的foo.a来编译依赖它的包:

//$GOPATH/src/bar.go

package main

import "github.com/bigwhite/foo"

func main() {
        foo.HelloGo()
}

# go build -o bar bar.go
# ./bar
Hello,Go

但是经过几个版本的迭代,Go team发现:对binary-only package越来越难以提供安全支持,无法保证binary-only package的编译使用的是与最终链接时相同的依赖版本,这很可能会造成因内存问题而导致的崩溃。并且经过调查,似乎用binary-only package的gopher并不多,并且gopher可以使用plugin、shared library、c-shared library等来替代binary-only package,以避免源码分发。于是Go 1.12版本将成为支持binary-only package的最后版本。

四. 运行时与标准库

经过Go 1.5~Go 1.10对运行时,尤其是GC的大幅优化和改善后,Go 1.11、Go 1.12对运行时的改善相比之下都是小幅度的。

在Go 1.12中,一次GC后的内存分配延迟得以改善,这得益于在大量heap依然存在时清理性能的提升。运行时也会更加积极地将释放的内存归还给操作系统,以应对大块内存分配无法重用已存在的堆空间的问题。在linux上,运行时使用MADV_FREE释放未使用的内存,这更为高效,操作系统内核可以在需要时重用这些内存。

在多CPU的机器上,运行时的timer和deadline代码运行性能更高了,这对于提升网络连接的deadline性能大有裨益。

标准库最大的改变应该算是对TLS 1.3的支持了。不过默认不开启。Go 1.13中将成为默认开启功能。大多数涉及TLS的代码无需修改,使用Go 1.12重新编译后即可无缝支持TLS 1.3。

另一个”有趣“的变化是syscall包增加了Syscall18,依据syscall包中函数名字惯例,Syscall18支持最多传入18个参数,这个函数的引入是为了Windows准备的。现在少有程序员会设计包含10多个参数的函数或方法了,这估计也是为了满足Windows中“遗留代码”的需求。

五. 工具链及其他

1. go安装包中移除go tour

go tour被从go的安装包中移除了,Go的安装包从go 1.4.x开始到go 1.11.x变得日益“庞大”:以linux/amd64的tar.gz包为例,变化趋势如下:

go 1.4.3:  53MB
go 1.5.4:  76MB
go 1.6.4:  83MB
go 1.7.6:  80MB
go 1.8.7:  96MB
go 1.9.7:  113MB
go 1.10.8: 97MB
go 1.11.5: 134MB
go 1.12:   121MB

后续预计会有更多的非核心功能将会从go安装包中移除来对Go安装包进行瘦身,即便不能瘦身,也至少要保持在现有的size水平上。

本次go tour被挪到:golang.org/x/tour中了,gopher们可单独安装tour:

# go get -u golang.org/x/tour

# tour //启动tour

Go 1.12也是godoc作为web server被内置在Go安装包的最后一个版本,在Go 1.13中该工具也会被从安装包中剔除,如有需要,可像go tour一样通过go get来单独安装。

2. Build cache成为必需

build cache在Go 1.10被引入以加快Go包编译构建速度,但是在Go 1.10和Go 1.11中都可以使用GOCACHE=off关闭build cache机制。但是在Go 1.12中build cache成为必需。如果设置GOCACHE=off,那么编译器将报错:

# GOCACHE=off  go build github.com/bigwhite/gocmpp
build cache is disabled by GOCACHE=off, but required as of Go 1.12

3. Go compiler支持-lang flag

Go compiler支持-lang flag,可以指示编译过程使用哪个版本的Go语法(注意不包括标准库变化等,仅限于语言自身语法)。比如:

//main.go

package main

import "fmt"

type Int = int

func main() {
        var a Int = 5
        fmt.Println(a)
}

# go run main.go
5

上面是一个使用了Go 1.9才引入的type alias语法的Go代码,我们使用Go 1.12可以正常编译运行它。但是如果我使用-lang flag,指定使用go1.8语法编译该代码,我们会得到如下错误提示:

# go build  -gcflags "-lang=go1.8" main.go
# command-line-arguments
./main.go:5:6: type aliases only supported as of -lang=go1.9

换成-lang=go1.9就会得到正确结果:

# go build  -gcflags "-lang=go1.9" main.go
# ./main
5


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

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

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

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

Go2 Error Inspection前瞻

这几年关于Go语言未来演化的讨论成为了Gopher世界的热点,Go team官方对于Go语言的演化(以Go2为标签)也是十分上心,但吸取了其他语言,比如:Python3割裂社区的、不兼容演化的教训,Go team最终选择了一条尽可能地兼容Go1、稳健、平滑的演化之路,并逐渐开始落地。Go 1.11Go modules是Go team开启Go2演化进程的标志性事件。随着“Go 2 Draft Design”发布,Go team正在努力着手解决Go社区反响较为强烈的Error handlingError valuesGenerics(泛型)这三个问题。从目前的进展上来看,Go error value相关机制的改善近期率先在以Proposal形式出现,并给出了待社区反馈的参考实现(golang.org/x/exp/xerrors),并很可能是继Go module之后第二个落地的Go2 特性。在本文中,我们就和大家一起来前瞻性探索一下Go2 error inspection及其参考实现。

一. Go2要解决关于Error的哪些问题

从全局角度,Go亟需解决的关于Error的问题包含两个大的方面,一个是Error handling机制,即尝试解决代码中大量重复出现下面代码的问题:

if err != nil {

   .... ....

}

第二个要解决的就是有关测试error变量值,并根据error变量值来选择后续代码执行路线的问题(面向机器),同时也要解决如何将error信息更完整、更全面地呈现给人的问题(面向人)。

关于error handling,draft引入了handle和check的新设计机制,该draft目前还在discuss之中;而第二个问题的解决正如我们前面提到的,已经率先成为Proposal并给出了参考实现,也是我们在本文中要重点探讨的内容。

Go error最初被创新地设计为一个interface:

type error interface {

    Error() string

}

这种设计是符合OCP(open-close principle)的,但是由于在error value test方面相对模糊且在标准库中缺少统一机制,导致gopher们在使用error时体验并不好。这里我们先来回顾一下在这之前我们是如何测试error变量值的。

1. 与预先定义好的知名error变量进行值相等测试 (以下称方法1)

如下面例子中,我们通过将ReadByte调用返回的err与io包中预定义的error变量: EOF(var EOF = errors.New(“EOF”))进行值测试,并根据测试结果选择接下来的代码执行路线:

func main() {
    reader := strings.NewReader("string reader buffer demo")

    for {
        s, err := reader.ReadByte()
        if err == io.EOF {
            fmt.Println("end")
            return
        } else if err != nil {
            fmt.Println(err)
            return
        }
        fmt.Printf("%c\n", s)
    }
}

对于预先已经定义的error变量,这样的error test方法是非常自然的,多数程序员从学习C语言那个时候就已经熟知该方法了。但是这种方法的局限就在于“扩展不足”。这些预定义好的error变量要么在标准库中,要么在依赖的第三方包中,我们只能使用这么多且这些变量所携带的信息有限。如果包中没有预定义或是想让这些变量携带更多对程序员有益的错误信息,我们就还得用其他办法来做error变量的值测试和扩展定义。

**2. 使用type assertion和type switch来测试是否是某种error的实现 **

标准库中net包中OpError的一些method中就采用了这种方式:

// $GOROOT/src/net/net.go

func (e *OpError) Timeout() bool {
    if ne, ok := e.Err.(*os.SyscallError); ok {
        t, ok := ne.Err.(timeout)
        return ok && t.Timeout()
    }
    t, ok := e.Err.(timeout)
    return ok && t.Timeout()
}

一些包还提供了一些专用方法来测试判定特定的error实现类型,比如:os包提供的IsNotExist、IsPermission等方法。不过这些方法在实现层面也都是使用的type assertion。

**3. 通过字符串匹配 **

由于缺少标准的、统一的error变量的值测试方法,尤其是针对重新wrapped的error变量(加上自己了的context信息,隐藏了underlying的error变量类型信息),在上述两种方法都无法使用的情况下,基于error变量Error()方法返回的string进行字符串匹配来进行error变量测试的手段成为了广大Gopher最后的“救命稻草”,但是这种方法也是最为“丑陋”的,是Go team最不希望gopher们使用的。

// 一个demo,现实中可能不存在这样的逻辑

func writeTxtFile(path string, content string) error {
    f, err := os.OpenFile("notes.txt", os.O_RDWR, 0755)
    if err != nil {
        return fmt.Errorf("open txt file: %s failed, reason: %s", path, err.Error())
    }

    defer f.Close()

    // ... write something
    _, err = f.Write([]byte(content))
    if err != nil {
        return fmt.Errorf("write to txt file: %s failed, reason: %s", path, err.Error())
    }

    return nil
}

func main() {
    err := writeTxtFile("./notes.txt", "write txt test")
    if err != nil {
        s := err.Error()
        if strings.Contains(s, "open txt file") {
            fmt.Println("open txt file error:", s) //但是我们仍然无法根据打开txt文件的具体原因类型(比如权限、还是文件不存在)做出相应的动作
            return
        }

        if strings.Contains(s, "write to txt file") {
            fmt.Println("write txt file error:", s)
            return
        }
    }
}

归根结底,fmt.Errorf提供的error wrap功能将最原始的error信息隐藏了起来,使得我们没有办法通过方法1或2来对wrapped的error变量进行值测试。这也是go2 error新方案要解决的问题。

二. xerrors的使用

下面我们来结合一下参考实现golang.org/x/exp/xerrors来看看该proposal是如何解决上述问题的。

1. wrapping error变量的创建

从前面的问题描述,我们知道Go2亟需提供一种简单的、标准的包裹(wrap)其他error变量并生成新error变量的方法,生成的新error变量中将包含被wrapped的error变量的信息:

img{512x368}

xerrors通过Errorf来提供这个功能。下面是参考上图函数调用和error变量包裹关系的一个Demo:

//github.com/bigwhite/experiments/xerrors/wrapper/wrapper1.go

func function4() error {
    return xerrors.New("original_error")
}

func function3() error {
    err := function4()
    if err != nil {
        return xerrors.Errorf("wrap3: %w", err)
    }
    return nil
}

func function2() error {
    err := function3()
    if err != nil {
        return xerrors.Errorf("wrap2: %w", err)
    }
    return nil
}

func function1() error {
    err := function2()
    if err != nil {
        return xerrors.Errorf("wrap1: %w", err)
    }
    return nil
}

func main() {
    err := function1()
    if err != nil {
        fmt.Printf("%v\n", err)
        return
    }

    fmt.Printf("ok\n")
}

通过xerror.Errorf对已知error变量进行包裹后,返回的error变量所归属的类型实现了error、xerrors.Formatter和xerrors.Wrapper接口,携带了被包裹(wrap)变量的信息,而传统的通过fmt.Errorf生成的error变量仅仅实现了error接口,没有被包裹的error变量的任何信息。这些携带的信息将在后续error变量值测试时(Is和As)以及error变量信息展示时被充分利用。

img{512x368}

我们运行一下上面的demo(默认得到单行的错误信息输出):

$go run wrapper1.go
wrap1: wrap2: wrap3: original_error

如果使用”+v%”输出error信息,我们将得到下面输出(多行):

$go run wrapper1.go
wrap1:
    main.function1
        /Users/tony/go/src/github.com/bigwhite/experiments/xerrors/wrapper/wrapper1.go:32
  - wrap2:
    main.function2
        /Users/tony/go/src/github.com/bigwhite/experiments/xerrors/wrapper/wrapper1.go:24
  - wrap3:
    main.function3
        /Users/tony/go/src/github.com/bigwhite/experiments/xerrors/wrapper/wrapper1.go:16
  - original_error:
    main.function4
        /Users/tony/go/src/github.com/bigwhite/experiments/xerrors/wrapper/wrapper1.go:10

我们看到”+v%”还输出每个错误变量生成时的位置信息,这是因为xerrors.Errorf生成的变量类型:wrapError中携带了“位置信息(frame Frame)”:

// golang.org/x/exp/xerrors/fmt.go

type wrapError struct {
    msg   string
    err   error
    frame Frame
}

上面的demo仅是为了演示通过xerrors.Errorf wrap的error variable携带了error chain的信息,并可以输出这些信息。下面我们来看看在函数调用的外部,如何对wrapped error variable进行各种值test。

2. error value test

对应上面提到方法1(等值测试)和方法2(type断言的类型测试),xerrors提供了对应的Is和As方法,这两个方法最大的不同就是可以针对wrapped error变量,在变量的error chain上做逐个进行测试,只要某个chain上的error变量满足要求,则返回true。我们分别来看看!

1) Is方法

xerrors的Is方法原型如下:

func Is(err, target error) bool

Is会将target与err中的error chain上的每个error 信息进行等值比较,如果相同,则返回true。我们用下面这幅图来诠释一下其原理:

img{512x368}

对应的测试代码见下面:

// github.com/bigwhite/experiments/xerrors/errortest/errortest1.go

func main() {
    err1 := xerrors.New("1")
    err2 := xerrors.Errorf("wrap 2: %w", err1)
    err3 := xerrors.Errorf("wrap 3: %w", err2)

    erra := xerrors.New("a")

    b := xerrors.Is(err3, err1)
    fmt.Println("err3 is err1? -> ", b)

    b = xerrors.Is(err2, err1)
    fmt.Println("err2 is err1? -> ", b)

    b = xerrors.Is(err3, err2)
    fmt.Println("err3 is err2? -> ", b)

    b = xerrors.Is(erra, err1)
    fmt.Println("erra is err1? -> ", b)
}

运行结果:

err3 is err1? ->  true
err2 is err1? ->  true
err3 is err2? ->  true
erra is err1? ->  false

2) As方法

Is方法是在error chain上做值测试。有些时候我们更方便做类型测试,即某一个err是否是某error类型。xerror提供了As方法:

func As(err error, target interface{}) bool

As会将err中的error chain上的每个error type与target的类型做匹配,如果相同,则返回true,并且将匹配的那个error var的地址赋值给target,相当于通过As的target将error chain中类型匹配的那个error变量析出。我们也用下面这幅图来诠释一下其原理:

img{512x368}

对应的测试代码见下面:

// github.com/bigwhite/experiments/xerrors/errortest/errortest2.go

type MyError struct{}

func (MyError) Error() string {
    return "MyError"
}

func main() {
    err1 := MyError{}
    err2 := xerrors.Errorf("wrap 2: %w", err1)
    err3 := xerrors.Errorf("wrap 3: %w", err2)
    var err MyError

    b := xerrors.As(err3, &err)
    fmt.Println("err3 as MyError? -> ", b)
    fmt.Println("err is err1? -> ", xerrors.Is(err, err1))

    err4 := xerrors.Opaque(err3)
    b = xerrors.As(err4, &err)
    fmt.Println("err4 as MyError? -> ", b)
    b = xerrors.Is(err4, err3)
    fmt.Println("err4 is err3? -> ", b)
}

运行结果:

err3 as MyError? ->  true
err is err1? ->  true
err4 as MyError? ->  false
err4 is err3? ->  false

我们看到As方法从err3的error chain中匹配到MyError类型的err1,并将err1赋值给err变量析出。在后续的Is测试也证实了这一点。代码中还调用了xerrors的Opaque方法,该方法将传入的支持unwrap操作的error变量转换为一个不支持unwrap的类型的error变量。在最后的对err4(通过Opaque调用得到)的测试我们也可以看到:err4无法匹配MyError type,与err3的等值测试也返回false。

三. 小结

以上就是xerrors提供的有关Go2 error inspection机制的主要功能。注意:xerrors及其proposal仍然可能会变动(包括设计和具体的实现),因此这里不能保证本文demo示例在后续的版本中依然可以编译运行。本文中的示例代码可以在这里得到。

目前go官方的golang.org/x/exp repo中有两个版本的实现:golang.org/x/exp/errors和golang.org/x/exp/xerrors。差别在于前者没有提供errors.Errorf。如果我们将wrapper1.go中的xerrors换成golang.org/x/exp/errors,则会在编译的时候出现下面错误:

$go run wrapper1.go
go: finding golang.org/x/exp/errors latest
go: downloading golang.org/x/exp/errors v0.0.0-20190125153040-c74c464bbbf2
# command-line-arguments
./wrapper.go:15:10: undefined: errors.Errorf
./wrapper.go:16:10: undefined: errors.Errorf
./wrapper.go:27:10: undefined: errors.Errorf
./wrapper.go:28:10: undefined: errors.Errorf

从官方的说明情况来看,golang.org/x/exp/errors将来要么进化到golang.org/x/errors,并作为Go标准库的vendor(类似于http/2) 包;要么直接merge到Go标准库中,然后该库作废(类似于vgo)。无论哪种形式,errors在merge后,会由fmt.Errorf来提供xerrors.Errorf的功能。

而golang.org/x/exp/xerrors则是可以用于任何版本的。

目前Go team给出的初步计划是在Go 1.13 dev cycle中将该Go 2 error inspection机制加入到main branch,并就像当年的http/2、vgo一样期待Gopher社区对该机制的反馈、然后优化,直到成熟并被广大Gopher所接受。


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我要发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

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

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

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

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

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

这里是 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

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats