本文索引
- 語言變化
- 數字字面量
- 越界索引報錯的完善
- 工具鏈改進
- GOPROXY
- GOSUMDB
- GOPRIVATE
- 標準庫的新功能
- 判斷變數是否為0值
- 錯誤處理的革新
- Unwrap
- Is
- As
golang1.13發布已經有一個月了，本文將會列舉其中幾個較為重要的特性，我們將會從語言變化、庫變化以及工具鏈的改進這三方面逐個介紹新版本中引入的新特性，
語言變化
go團隊一直承諾1.x版本的向前兼容，所以雖然1.13作為第一個開始向go2過渡的版本，其引入的語言變化是極少的，主要只有這兩點：更多的數字字面量和改進的panic資訊，
數字字面量
數字字面量是大家再熟悉不過的東西了，比如100，0.99，1.等，
然而奇怪的是，1.13之前的golang僅支持10進制和16進制的字面量，而在其它語言中廣泛支持的二進制和八進制卻不受支持，例如下面的代碼是無法編譯的：
fmt.Println(0b101)
fmt.Println(0o10)
在go1.13中上述字面量語法已經被支持了你可以通過0b或0B前綴來表明一個二進制數字的字面量，以及用0o和0O來表明八進制字面量，值得注意的是雖然兩種寫法都可以，但是gofmt默認會全部轉換為小寫，所以我更推薦使用0b和0o使你的代碼風格盡量統一，
數字字面量的另一個變化就是引入了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的：
- go get下載的package會根據go.mod檔案和所有下載檔案分別建立一個hash字串，存盤在go.sum檔案中；
- 下載的package會被cache，每次編譯或者手動go mod verify時會重新計算與go.sum中的值比較，出現不一致就會報安全錯誤，
這個機制是建立在本地的cache在整個開發生命周期中不會變動之上的（因為依賴庫的版本很少會進行更新，除非出現重大安全問題），上述機制可以避免他人誤更新依賴或是本地的惡意篡改，然而現在更多的安全問題是發生在遠程環境的，因此這一機制有很大的安全隱患，
好在加入了GOSUMDB，它的默認值為“sum.golang.org”，國內部分地區無法訪問，可以改為“sum.golang.google.cn”，現在的作業機制是這樣的：
- go get下載包并計算校驗和，計算好后會先檢查是否已經出現在go.sum檔案中，如果沒有則去GOSUMDB中檢查，校驗和一致則寫入go.sum檔案；否則報錯
- 如果對應版本的包的校驗和已經在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，String和Error方法都是常規的自定義錯誤中會實作的方法，我們重點看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這樣的代碼，
當然，上面的函式一方面讓你少寫了很多代碼，另一方面又嚴重依賴反射，特別是錯誤鏈很長的時候需要反復追溯多次，所以這里有兩條忠告：
- 不要過渡包裝，沒什么是加間接層解決不了的，但是中間層太多不僅影響性能也會干擾后續維護；
- 如果你實在在意性能，而且保證不存在對現有error的擴展（例如io.EOF），那么使用傳統方案也無傷大雅，
就個人而言我不認為新的錯誤處理方法解決了什么本質的問題，但作為邁出嘗試的第一步，還是值得肯定的，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/71602.html
標籤：Go
上一篇：Go語言開發環境搭建