引言

Go 的錯誤處理一直是表現(xiàn)最突出的一塊地方，許許多多的同學(xué)都提出了各種提案，例如：引入 try-catch、用 panic 代替 if err != nil、引入新的關(guān)鍵字等。但這些都被一一駁回了。

不過社區(qū)依然還沒放棄，周末看到有一個新的提案《proposal: runtime: add parameters to recover to only return specific types》挺有意思。

語法說明

Go 的 panic、recover、defer 的基本使用方式。如下代碼：

package main
import "fmt"
func mayPanic() {
 panic("a problem")
}
func main() {
 defer func() {
  if r := recover(); r != nil {
fmt.Println("Recovered. Error:\n", r)
  }
 }()
 mayPanic()
 fmt.Println("After mayPanic()")
}

輸出結(jié)果：

Recovered. Error:
a problem

新提案

由于有 Go1 兼容性保障，新提案是在原有的 recover 函數(shù)上動小手術(shù)。希望可以現(xiàn)在運行時的 recover 中加入?yún)?shù)，僅支持返回特定的類型。

函數(shù)簽名：

recover(except ...interface{})

案例代碼：

defer func(){
 if err := recover(&MyError{}, &HelloError{}); err != nil {
  switch e := err.(type) {
  case *MyError:
fmt.Println(e)
  case *HelloError:
fmt.Println(e)
  }
 }
}

上面代碼中，recover 函數(shù)只支持傳入 MyError 和 HelloError 的指針類型。再在處理邏輯中根據(jù)所傳入的錯誤類型，進行斷言分類，實際上去做不同的邏輯處理。

重點就是限定 recover 入?yún)㈩愋汀?/p>

討論

有些小伙伴可能發(fā)現(xiàn)了，對比看看 PHP 的 try-catch 的用法，與前面的提案代碼是不是有好幾分神似呢？

如下代碼：

try {
 ...
}
catch (Exception $e) {
 echo $e->getMessage();
}
catch (InvalidArgumentException $e) {
 echo $e->getMessage();
}
catch (BarException $ex)
{
 echo $e->getMessage();
}
catch (FooException $ex)
{
 echo $e->getMessage();
}

本質(zhì)上這個新的提案是想在不破壞 Go1 兼容性的情況下，在 Go 中實現(xiàn) try-catch 的方式。

社區(qū)在交流時，也發(fā)現(xiàn)了用戶在現(xiàn)有機制下可以自主實現(xiàn) Go 的類 try-catch 的模式。

如下代碼：

func Recover(expect ...interface{}) interface{} {
 if err := recover(); err != nil {
  if len(expect) == 0 {
return err
  }
  rv1 := reflect.Indirect(reflect.ValueOf(err))
  for _, e := range expect {
rv2 :=  reflect.Indirect(reflect.ValueOf(e))
if rv1.Type() == rv2.Type() {
 return err
}
  }
  panic(err)
 }
 return nil
}

這個自制方法的問題是每次 Recover panic 都會將堆棧深度增加 2。因此還是寄希望于 Go 官方能夠在運行時支持。

在 Go 標準庫的用途對比上，也有產(chǎn)生一定的作用，其涉及到的代碼基本為：

總結(jié)

這個提案本質(zhì)上是希望通過在 recover 函數(shù)中增加入?yún)⒖刂疲倥浜蟽?nèi)部邏輯實現(xiàn)類似 Go 版本的 try-catch 的錯誤處理機制模型，且實際在 Go 標準庫中有復(fù)用的空間。

但現(xiàn)階段該提案也是贊同和反對參半，也有人認為可以用戶自己實現(xiàn)，那就沒必要加大復(fù)雜度，去做這個收益不夠大的實現(xiàn)。

你覺得這能補全 Go 錯誤處理的一些機制缺陷嗎？

以上就是分析Go錯誤處理優(yōu)化go recover機制缺陷的詳細內(nèi)容，更多關(guān)于go recover錯誤處理的資料請關(guān)注本站其它相關(guān)文章！

美國快速服務(wù)器

版權(quán)聲明：本站文章來源標注為YINGSOO的內(nèi)容版權(quán)均為本站所有，歡迎引用、轉(zhuǎn)載，請保持原文完整并注明來源及原文鏈接。禁止復(fù)制或仿造本網(wǎng)站，禁止在非www.sddonglingsh.com所屬的服務(wù)器上建立鏡像，否則將依法追究法律責(zé)任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學(xué)習(xí)參考，不代表本站立場，如有內(nèi)容涉嫌侵權(quán)，請聯(lián)系alex-e#qq.com處理。