哪一個更好呢？
1
err := MakeFood()
if err != nil{
return err
}
2
err := MakeFood()
if err != nil{
logs.Errorf(" failed to make food, error=%v", err)
return err
}
3
err := MakeFood()
if err != nil{
return fmt.Errorf(" failed to make food, error=%w", err)
}
4
var ErrMakeFood = errors.New(" failed to make food")
err := MakeFood()
if err != nil{
return ErrMakeFood //我們丟棄err。
}
在我的實踐中，return fmt.Errorf("xxx, error=%w",err)是我最喜歡的，它在錯誤發生時創建一個級聯的錯誤字串并回傳。
但似乎，在go builtin src代碼中，return err是正常和整潔的。
有時我們被建議使用靜態錯誤宣告（我給出的例子4）。這是一個名為goerr113的golang-lint的lint規則，
uj5u.com熱心網友回復：
沒有一個是更好的，它們都是不同的，可以適用于不同的情況。
第一種，
err := MakeFood()
if err != nil{
return err
}
當MakeFood已知為其回傳的所有錯誤提供自己的背景關系（或包裹并回傳--"冒泡"）時，是可以的；例如，它曾經回傳的任何錯誤都被包裹在 "制作食物失敗："的背景關系中。
它也適用于其他不需要提供任何額外背景關系的情況。
第二種和第三種適合于執行由多個步驟組成的概念上單一（原子）任務的大型函式的背景關系（制作食物是其中的一個步驟）；在這種情況下，習慣于將每個步驟報告的錯誤包裹在相同的背景關系中，當呼叫鏈中的每個呼叫添加其自身的背景關系時，就會導致背景關系 "鏈"。
func ProcessFoodDeliveryOrder() error {
餐點, err := MakeFood()
if err != nil {
return fmt.Errorf(" failed to process order: %w"/span>, err)
}
err := Deliver(meat, address)
if err != nil {
return fmt.Errorf(" failed to process order: %w"/span>, err)
}
return nil
}
是否應該使用較新的Go設施，通過使用%w格式化動詞來實際嵌套錯誤，而不是僅僅提供文本（訊息）背景關系，這是一個開放的問題：不是所有的錯誤都需要被包裝（然后再通過errors. Is或由errors.As處理）；沒有必要僅僅因為你知道它的存在和看起來很酷而使用該設施：它有其運行時成本。
錯誤資訊最好使用普通的: %s組合式的fmt.Errorf("new context: %s", err)，因為用這種方式來改變錯誤產生一個簡單易懂的 "action: reason "文本。The Book中推薦了這種方法。
后一種方法被稱為 "一個哨兵錯誤"。如果你的包的用戶真的會使用這樣的錯誤變數--直接或通過使用errors.Is測驗它，那么使用是可以的。
但是也要考慮到，最好是斷言錯誤的行為，而不是將它們與一個哨兵變數相比較。考慮閱讀這個，看看net.Error。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/313774.html
標籤：
上一篇：GoLang：為什么在沒有變數宣告的情況下，運算子的地址不作業？
下一篇：用于比較專案的URL結構