1. 程式人生 > >golang1.13中重要的新特新

golang1.13中重要的新特新

本文索引

  • 語言變化
    • 數字字面量
    • 越界索引報錯的完善
  • 工具鏈改進
    • GOPROXY
    • GOSUMDB
    • GOPRIVATE
  • 標準庫的新功能
    • 判斷變數是否為0值
    • 錯誤處理的革新
      • Unwrap
      • Is
      • As

golang1.13釋出已經有一個月了,本文將會列舉其中幾個較為重要的特性。我們將會從語言變化、庫變化以及工具鏈的改進這三方面逐個介紹新版本中引入的新特性。

語言變化

go團隊一直承諾1.x版本的向前相容,所以雖然1.13作為第一個開始向go2過渡的版本,其引入的語言變化是極少的,主要只有這兩點:更多的數字字面量和改進的panic資訊。

數字字面量

數字字面量是大家再熟悉不過的東西了,比如1000.991.等。

然而奇怪的是,1.13之前的golang僅支援10進位制和16進位制的字面量,而在其它語言中廣泛支援的二進位制和八進位制卻不受支援。例如下面的程式碼是無法編譯的:

fmt.Println(0b101)
fmt.Println(0o10)

在go1.13中上述字面量語法已經被支援了你可以通過0b0B字首來表明一個二進位制數字的字面量,以及用0o0O來表明八進位制字面量。值得注意的是雖然兩種寫法都可以,但是gofmt預設會全部轉換為小寫,所以我更推薦使用0b0o使你的程式碼風格儘量統一。

數字字面量的另一個變化就是引入了16進位制浮點數的支援。

16進位制浮點數是按照16進位制來表示浮點數的方法,需要注意的是這裡指的不是將浮點數表示為對應二進位制值的16進位制形式,而是形式如下的16進位制數字:

0X十六進位制整數部分.十六進位制小數部分p指數

其中整數和小數部分和普通浮點字面量一樣可以省略,省略的部分預設為0。p+指數的部分不可省略,指數可以有符號,它的值是2的指數。

一個16進位制浮點字面量最終的結果,假設p之前的部分的值為a,p後的指數是b,最終的值如下:a * 2^b

看上去和科學計數法很像,事實上也就是把e換成了p,指數計算從10變為了2。另外因為是每16進1,所以0x0.1p0看上去像0.1,然而它表示的是1/16,而0x0.01p0則是1/16的1/16,初見會不太直觀,但是習慣後就不會有什麼問題了。舉點例子:

二進位制和八進位制字面量是比較常用的,那16進位制浮點數呢?答案是更高的精度和統一的表達。

0x0.1p0表示的十進位制值是0.0625,而0x0.01p0是0.00390625,已經超過了float32的精度範圍,所以16進位制浮點字面量可以在有限的精度範圍內表示更精確的數值。統一表達自然不用多解釋,習慣16進製表達的開發者更樂於使用類似形式。

具體的示例可以參考這裡。

最後對於數字字面量還有一個小小的改進,那就是現在可以用下劃線分隔數字增加可讀性。舉個例子:

fmt.Println(100000000)
fmt.Println(1_0000_0000)
fmt.Println(0xff_ff_ff)

分隔符可以出現在任意位置,但是像0x之類的算是一個完整的符號的中間不可以插入下劃線,分隔符之間字元的數量沒有規定必須相等,但為了可讀性最好按照現有的習慣每3個數字或四個數字進行一次分隔。

越界索引報錯的完善

雖然我將其歸為語言變化,但事實上將其定義為執行時改進更為恰當。

眾所周知golang對陣列和slice的越界引用是0容忍的,一旦越界就會panic,例如下面的例子:

package main

import "fmt"

func main() {
        arr := [...]int{1,2,3,4,5}
        for i := 0; i <= len(arr); i++ {
                fmt.Println(arr[i])
        }
}

如果執行這個程式那麼你會收到一個不短的抱怨:

這裡的例子很簡單,所以呼叫堆疊資訊追溯起來不是很困難,可以方便得定位問題,但如果呼叫鏈較深或者你處於一個高併發程式之中,事情就變得麻煩了,要麼依賴日誌除錯並最終分析排除大量雜音來定位問題,要麼依賴斷點進行單步除錯,無論哪種都需要耗費大量的精力,而核心問題只是我們想直到為什麼會越界,再淺一步,我們有時候或許只要知道導致越界的值就可以大致確定問題的原因,遺憾的是panic提供的資訊中不包含上述內容,直到golang1.13。

現在golang會將導致越界的值打印出來,無疑是雪中送碳:

當然,panic資訊再完善也不是靈丹妙藥,完善的單元測試和嚴謹的工作態度才是bug最好的預防針。

工具鏈改進

語言層面的變動不是很大,但工具鏈就不一樣了,除了去除了godoc程式,最大的變化仍舊集中在go modules上。

這次golang加入了三個環境變數來共同控制modules的行為,下面分別進行介紹。

GOPROXY

其實這個變數在1.12中就引入了,這次為其加上了預設值https://proxy.golang.org,direct,這是一個逗號分隔的列表,後面兩個變數的值和它相同,其中direct表示不經過代理直接連線,如果設定為off,則進位制下載任何package。

在go get等命令獲取package時,會從左至右依次查詢,如果都沒有找到匹配的package,則會報錯。

proxy的好處自然不用多說,它可以使國內開發者暢通無阻地訪問某些國內環境無法獲取的包。更重要的是預設的proxy是官方提供和維護的,比起第三方方案來說安全性有了更大的保障。

GOSUMDB

這個變數實際上相當於指定了一個由官方管理的線上的go.sum資料庫。具體介紹之前我們先來看看golang是如何驗證packages的:

  1. go get下載的package會根據go.mod檔案和所有下載檔案分別建立一個hash字串,儲存在go.sum檔案中;
  2. 下載的package會被cache,每次編譯或者手動go mod verify時會重新計算與go.sum中的值比較,出現不一致就會報安全錯誤。

這個機制是建立在本地的cache在整個開發生命週期中不會變動之上的(因為依賴庫的版本很少會進行更新,除非出現重大安全問題),上述機制可以避免他人誤更新依賴或是本地的惡意篡改,然而現在更多的安全問題是發生在遠端環境的,因此這一機制有很大的安全隱患。

好在加入了GOSUMDB,它的預設值為“sum.golang.org”,國內部分地區無法訪問,可以改為“sum.golang.google.cn”。現在的工作機制是這樣的:

  1. go get下載包並計算校驗和,計算好後會先檢查是否已經出現在go.sum檔案中,如果沒有則去GOSUMDB中檢查,校驗和一致則寫入go.sum檔案;否則報錯
  2. 如果對應版本的包的校驗和已經在go.sum中,則不會請求GOSUMDB,其餘步驟和舊機制一樣。

安全性得到了增強。

GOPRIVATE

最後要介紹的是GOPRIVATE,預設為空,你可以在其中使用類似Linux glob萬用字元的語法來指定某些或某一類包不從proxy下載,比如某些rpc套件自動生成的package,這些在proxy中並不會存在,而且即使上傳上去也沒有意義,因此你需要把它寫入GOPRIVATE中。

還有一個與其類似的環境變數叫GONOPROXY,值的形式一樣,作用也基本一樣,不過它會覆蓋GOPRIVATE。比如將其設為none時所有的包都會從proxy進行獲取。

從這些變化來看go團隊始終在尋找一種能細粒度控制的統一的包管理解決方案,雖然目前和npm、pypi還有巨大的差距,但仍不失為成功道路上的堅實一步。

標準庫的新功能

每次新版本釋出都會給標準庫帶來大把的新功能新特性,這次也不例外。

本節會介紹一個小的新功能,以及一個重要的新變化。

判斷變數是否為0值

golang中任何型別的0值都有明確的定義,然而遺憾的是不同的型別0值不同,特別是那些自定義型別,如果你要判斷一個變數是否0值那麼將會寫出複雜繁瑣而且擴充套件困難的程式碼。

因此reflect中新增了這一功能簡化了操作:

package main

import (
        "fmt"
        "reflect"
)

func main() {
        a := 0
        b := 1
        c := ""
        d := "a"
        fmt.Println(reflect.ValueOf(a).IsZero()) // true
        fmt.Println(reflect.ValueOf(b).IsZero()) // false
        fmt.Println(reflect.ValueOf(c).IsZero()) // true
        fmt.Println(reflect.ValueOf(d).IsZero()) // false
}

當然,反射一勞永逸的代價是更高的效能消耗,所以具體取捨還要參照實際環境。

錯誤處理的革新

其實算不上革新,只是對現有做法的小修小補。golang團隊始終有覺得error既然是值那就一定得體現value的equal操作的怪癖,所以整體上還是很怪。

首先要介紹錯誤鏈(error chains)的概念。

在1.13中,我們可以給error實現一個Unwrap的方法,從而實現對error的包裝,比如:

type PermError {
        os.SyscallError
        Pid uint
        Uid uint
}

func (err *PermError) String() string {
        return fmt.Sprintf("permission error:\npid:%v\nuid:\ninfo:%v", err.Pid, err.Uid, err.SyscallError)
}

func (err *PermError) Error() string {
        return err.String()
}

// 重點在這裡
func (err *PermError) Unwrap() error {
        return err.SyscallError
}

假設我們包裝了一個基於SyscallError的許可權錯誤,包括了所有因為許可權問題而觸發的error。StringError方法都是常規的自定義錯誤中會實現的方法,我們重點看Unwrap方法。

Unwrap字面意思就是去包裝,也就是我們把包裝好的上一層錯誤重新分離出來並返回。os.SyscallError也實現了Unwrap,於是你可以繼續向上追溯直達最原始的沒有實現Unwrap的那個error為止。我們稱從PermError開始到最頂層的error為一條錯誤鏈。

如果我們用→指向Unwrap返回的物件,會形成下面的結構:

PermError → os.SyscallError → error

還可以出現更復雜的結構:
A → Err1 ___________
|
V
B → Err2 → Err3 → error

這樣無疑提升了錯誤的表達力,如果不想自己單獨定義一個錯誤型別,只想附加某些資訊,可以依賴fmt.Errorf

newErr := fmt.Errorf("permission error:\npid:%v\nuid:\ninfo:%w", pid, uid, sysErr)
sysErr == newErr.(interface {Unwrap() error}).Unwrap()

fmt.Errorf新的佔位符%w只能在一個格式化字串中出現一次,他會把error的資訊填充進去,然後返回一個實現了Unwrap的新error,它返回傳入的那個error。另外提案裡的Wrapper介面目前還沒有實現,但是標準庫用了我在上面的做法暫時實現了Wrapper的功能。

因為錯誤鏈的存在,我們不能在簡單的用等於號基於判斷基於值的error了,但好處是我們現在還可以判斷基於型別的error。

為了能繼續讓error表現自己的值語義,errors包裡增加了Is和As以及輔助它們的Unwrap函式。

Unwrap

errors.Unwrap會呼叫傳入引數的Unwrap方法,As和Is使用它來追溯整個錯誤鏈。

像上一小節的程式碼就可以簡化成這樣:

newErr := fmt.Errorf("permission error:\npid:%v\nuid:\ninfo:%w", pid, uid, sysErr)
sysErr == errors.Unwrap(newErr).Unwrap()

Is

我們提到等於號的比較很多時候已經不管用了,有的時侯一個error只是對另一個的包裝,當這個error產生時另一個也已經發生了,這時候我們只需要比較處於上層的error值即可,這時候你就需要errors.Is幫忙了:

newErr := fmt.Errorf("permission error:\npid:%v\nuid:\ninfo:%w", pid, uid, sysErr)
errors.Is(newErr, sysErr)
errors.Is(newErr, os.ErrExists)

你永遠也不知道程式會被怎樣擴充套件,也不知道error之間的關係未來會怎樣變化,因此總是用Is代替==是不會犯錯的。

不過凡事總有例外,例如io.EOF就不需要使用Is去比較,因為它程式意義上算不上是error,而且一般也不會有人包裝它。

As

除了傳統的基於值的判斷,對某個型別的錯誤進行處理也是一個常見需求。例如前文的A,B都來自error,假設我們現在要處理所有基於這個error的錯誤,常見的辦法是switch進行比較或者依賴於基類的多型能力。

顯而易見的是switch判斷的做法會導致大量重複的程式碼,而且擴充套件困難;而在golang裡沒有繼承只有組合,所以有執行時多型能力的只有interface,這時候我們只能藉助錯誤鏈讓errors.As幫忙了:

// 注意As的第二個引數只能是你需要判斷的型別的指標,不可以直接傳一個nil進去
var p1 *os.SyscallError
var p2 *os.PathError
errors.As(newErr, &p1)
errors.As(newErr, &p2)

如果p1和p2的型別在newErr所在的錯誤鏈上,就會返回true,實現了一個很簡陋的多型效果。As總是用於替代if _, ok := err.(type); ok這樣的程式碼。

當然,上面的函式一方面讓你少寫了很多程式碼,另一方面又嚴重依賴反射,特別是錯誤鏈很長的時候需要反覆追溯多次,所以這裡有兩條忠告:

  1. 不要過渡包裝,沒什麼是加間接層解決不了的,但是中間層太多不僅影響效能也會干擾後續維護;
  2. 如果你實在在意效能,而且保證不存在對現有error的擴充套件(例如io.EOF),那麼使用傳統方案也無傷大雅。

就個人而言我不認為新的錯誤處理方法解決了什麼本質的問題,但作為邁出嘗試的第一步,還是值得肯定的