2 回答

TA貢獻(xiàn)1796條經(jīng)驗(yàn) 獲得超7個(gè)贊
這是一個(gè)常見的抱怨,對此有多種答案。
以下是一些常見的:
1 - 還不錯(cuò)
這是對這些投訴的一種非常普遍的反應(yīng)。事實(shí)上,你的代碼中有幾行額外的代碼實(shí)際上并沒有那么糟糕。這只是一點(diǎn)點(diǎn)廉價(jià)的打字,而且在閱讀方面很容易處理。
2 - 這實(shí)際上是一件好事
這是基于這樣一個(gè)事實(shí),即輸入和閱讀這些額外的行是一個(gè)很好的提醒,實(shí)際上您的邏輯可能會(huì)在此時(shí)逃逸,并且您必須撤消在它之前的行中放置的任何資源管理。這通常是與異常相比提出的,異??梢噪[式地破壞邏輯流程,迫使開發(fā)人員始終牢記隱藏的錯(cuò)誤路徑。前段時(shí)間我在這里寫了一篇關(guān)于這個(gè)的更深入的咆哮。
3 - 使用恐慌/恢復(fù)
在某些特定情況下,您可以通過使用panic已知類型來避免其中的一些工作,然后recover在您的包代碼發(fā)布之前使用,將其轉(zhuǎn)換為正確的錯(cuò)誤并返回。這種技術(shù)最常用于展開遞歸邏輯,例如 (un) marshalers。
我個(gè)人盡量不要過度濫用這一點(diǎn),因?yàn)槲遗c第 1 點(diǎn)和第 2 點(diǎn)的相關(guān)性更緊密。
4 - 稍微重新組織一下代碼
在某些情況下,您可以稍微重新組織邏輯以避免重復(fù)。
作為一個(gè)簡單的例子,這個(gè):
err := doA()
if err != nil {
return err
}
err := doB()
if err != nil {
return err
}
return nil
也可以組織為:
err := doA()
if err != nil {
return err
}
return doB()
5 - 使用命名結(jié)果
有些人使用命名結(jié)果從 return 語句中去除 err 變量。不過,我建議不要這樣做,因?yàn)樗?jié)省的代碼很少,降低了代碼的清晰度,并且當(dāng)一個(gè)或多個(gè)結(jié)果在救助返回語句之前定義時(shí),會(huì)使邏輯容易出現(xiàn)微妙的問題。
6 - 在 if 條件之前使用語句
正如 Tom Wilde 在下面的評論中很好地提醒的那樣,ifGo 中的語句在條件之前接受一個(gè)簡單的語句。所以你可以這樣做:
if err := doA(); err != nil {
return err
}
這是一個(gè)很好的 Go 習(xí)語,并且經(jīng)常使用。
在某些特定情況下,我寧愿避免以這種方式嵌入語句,只是為了清楚起見使其獨(dú)立,但這是一件微妙且個(gè)人的事情。

TA貢獻(xiàn)1826條經(jīng)驗(yàn) 獲得超6個(gè)贊
您可以使用命名返回參數(shù)來縮短一些事情
func doStuff() (result string, err error) {
a, err := doA()
if err != nil {
return
}
b, err := doB(a)
if err != nil {
return
}
result, err = doC(b)
if err != nil {
return
}
return
}
在你用 Go 編程一段時(shí)間后,你會(huì)意識到必須檢查每個(gè)函數(shù)的錯(cuò)誤會(huì)讓你思考如果該函數(shù)出錯(cuò),它實(shí)際上意味著什么,以及你應(yīng)該如何處理它。
- 2 回答
- 0 關(guān)注
- 222 瀏覽
添加回答
舉報(bào)