我們有用go編寫的中等大小的應用程序。從所有代碼行中,大約百分之六十進行代碼錯誤處理。事情是這樣的:用所有錯誤處理的恐慌替換golang錯誤代碼
if err != nil {
return err
}
過了一段時間,一遍又一遍寫這行變得無聊,現在我們正在考慮用恐慌來代替所有的錯誤代碼。
我知道恐慌並不意味着要這樣使用。
什麼可能是潛在的陷阱,有沒有人有類似的經驗?
我們有用go編寫的中等大小的應用程序。從所有代碼行中,大約百分之六十進行代碼錯誤處理。事情是這樣的:用所有錯誤處理的恐慌替換golang錯誤代碼
if err != nil {
return err
}
過了一段時間,一遍又一遍寫這行變得無聊,現在我們正在考慮用恐慌來代替所有的錯誤代碼。
我知道恐慌並不意味着要這樣使用。
什麼可能是潛在的陷阱,有沒有人有類似的經驗?
主要陷阱將是錘子驅動螺絲的廣泛使用。 恐慌是針對不可恢復/意外的錯誤,錯誤返回值是針對可恢復/預期的錯誤。
將「恐慌」一詞替換爲「崩潰」,因爲這在概念上是一種恐慌。你是否真的想編寫一個應用程序設計崩潰時,任何事情以任何方式遠程錯誤?這將是地球上最脆弱的應用,這與容錯的對立面非常相似。
由於所有的評論都表明你可以註冊一個災難並讓我補充說,無論誰要維護這段代碼都會瘋狂地試圖弄清楚如果你不做適當的錯誤處理(即使那個人是你,它會困擾你)。
只是在重複別人怎麼說的 - 問題是無法這兩
恐慌是儲備d爲後者類型。
祝你好運恢復在這個過程中發生的傷害。恕我直言,這是一個瘋狂的想法。 – Volker
錯誤是正常值,當你開始恐慌像'io.EOF'這樣的預期錯誤時,它會很難。 if語句是否真的比恐慌更難打字? (順便說一下,如果你不想輸入它們,請讓你的編輯器提供常用的片段) – JimB