更新：我認為現(xiàn)在這個問題沒有普遍的答案。我們可以使用答案中解釋的技術(shù)返回這兩個錯誤。我認為這里最重要的是不要忘記當我們有兩個錯誤時的情況并以某種方式處理它。注意：SO上有很多關(guān)于如何從延遲函數(shù)返回錯誤的問題。這不是這里的問題。（在 Go 中）當函數(shù)已經(jīng)返回錯誤時，從延遲函數(shù)返回錯誤的正確方法是什么。例如_func errorMaker() (err error) {? ? defer func() {? ? ? ? err = errors.New("Deferred error")? ? }()? ? err = errors.New("Some error")? ? return}func main() {? ? err := errorMaker()? ? fmt.Printf("Error: %v\n", err)}在上面的代碼中，延遲函數(shù)返回的錯誤會覆蓋該函數(shù)返回的錯誤。返回這兩個錯誤的規(guī)范方法是什么？如果另一個程序員使用我的函數(shù)，當函數(shù)返回“兩個錯誤”時，她期望從函數(shù)中得到什么結(jié)果？我應(yīng)該為此使用錯誤包裝嗎？
1 回答
茅侃侃
TA貢獻1842條經(jīng)驗 獲得超22個贊
免責(zé)聲明：我不知道以下建議是否可以被視為“標準”或“廣泛接受”。
我應(yīng)該為此使用錯誤包裝嗎？
簡短的回答：是的（我會這樣做）。
Go 1.12 及更早版本
當我需要錯誤來傳達某些特定含義時，我會做什么，而不放棄接口error，我創(chuàng)建一個實現(xiàn)錯誤接口的包裝器 - Error() string-。該包裝包含我需要的所有額外信息。
如果調(diào)用者知道這些額外信息的存在，它可以通過強制轉(zhuǎn)換來解開錯誤并找到這些信息。額外的好處是，不知情的調(diào)用者可以將錯誤作為通用的error.
type MyError struct {
DeferredError error
}
// Implements 'error' interface
func (e MyError) Error() string {
// format to string
}
func someFunc() error {
// might return an instance of MyError
}
...
// Caller code
err := someFunc()
if err != nil {
if myErr, ok := err.(*MyError); ok {
// here you can access the wrapped info
fmt.Println(myErr.DeferredError)
} else {
// otherwise handle the error generically
}
}
轉(zhuǎn)到 1.13 及以上
使用 Go.13，您可以用來errors.As解開錯誤。來自官方文檔：
[方法] As 查找 err 鏈中與 target 匹配的第一個錯誤，如果是，則將 target 設(shè)置為該錯誤值并返回 true。該鏈由 err 本身和通過重復(fù)調(diào)用 Unwrap 獲得的錯誤序列組成。
var myErr *MyError
if errors.As(err, &myErr) {
// here you can access the wrapped info
fmt.Println(myErr.DeferredError)
} else {
// otherwise handle the error generically
}
正如文檔所說，該myErr變量是作為調(diào)用的副作用而填充的As。
- 1 回答
- 0 關(guān)注
- 103 瀏覽
添加回答
舉報
0/150
提交
取消