來自 100 個代碼覆蓋率問題的評論之一說：...在絕大多數情況下log.Fatal應該只在 main 或 init 函數中使用（或者可能是一些只能直接從它們調用的東西）”這讓我思考，所以我開始查看 Go 提供的標準庫代碼。庫中的測試代碼使用了很多示例，這些示例log.Fatal看起來不錯。在測試代碼之外還有一些示例，例如在 中net/http，如下所示：// net/http/transport.go func (t *Transport) putIdleConn(pconn *persistConn) bool { ... for _, exist := range t.idleConn[key] { if exist == pconn { log.Fatalf("dup idle pconn %p in freelist", pconn) } } ...}如果它是避免使用 的最佳實踐log.Fatal，為什么在標準庫中使用它，我會期望只返回一個錯誤。對于庫的用戶來說，導致os.Exit被調用而不為應用程序提供任何清理機會似乎是不公平的。我可能很天真，因此作為更好的實踐，我的問題似乎是調用log.Panic哪些可以恢復，并且我理論上的長期運行穩定的應用程序可能有機會從灰燼中崛起。那么對于 Go 什么時候應該使用 log.Fatal 的最佳實踐是什么？
2 回答
守著一只汪
TA貢獻1872條經驗 獲得超4個贊
這可能只是我，但這是我如何使用log.Fatal. 根據 UNIX 約定，遇到錯誤的進程應盡早失敗并返回非零退出代碼。這使我在以下情況下使用以下準則log.Fatal......
...在任何 my 中都會發生錯誤
func init()，因為它們分別在處理導入時或調用 main func 之前發生。相反，我只做不直接影響庫或 cmd 應該做的工作單元的事情。例如，我設置日志記錄并檢查我們是否擁有健全的環境和參數。如果我們有無效標志，就不需要運行 main，對嗎？如果我們不能給出適當的反饋，我們應該早點說出來。…發生了我知道無法恢復的錯誤。假設我們有一個程序可以創建命令行上給出的圖像文件的縮略圖。如果此文件不存在或由于權限不足而無法讀取，則沒有理由繼續并且無法從中恢復此錯誤。所以我們遵守約定而失敗。
……在可能不可逆的過程中發生錯誤。我知道，這是一種軟定義。讓我來說明一下。假設我們有一個實現
cp，并且它開始是非交互式并遞歸復制目錄。現在，讓我們假設我們在目標目錄中遇到一個文件，該文件與要復制到那里的文件具有相同的名稱（但內容不同）。由于我們無法要求用戶決定要做什么并且我們無法復制此文件，因此我們遇到了問題。因為當我們完成退出代碼為零時，用戶會假設源目錄和目標目錄是完全相同的副本，所以我們不能簡單地跳過有問題的文件。但是，我們不能簡單地覆蓋它，因為這可能會破壞信息。這是一種我們無法從用戶的每個明確請求中恢復log.Fatal的情況，所以我會用這種情況來解釋這種情況，特此遵循盡早失敗的原則。
藍山帝景
TA貢獻1843條經驗 獲得超7個贊
我認為它非常好，非常有見地，我傾向于同意你的崩潰。很難一概而論，盡管作為 Go 的新手，我一直在考慮更多。我認為在理論層面上，如果我們尋求計算中的最佳實踐，無論操作系統、包框架或庫如何，記錄器的責任就是簡單地記錄。在任何級別，記錄員的職責：
將信息格式化和打印到我選擇的頻道。
分類、過濾、顯示不同的日志級別 [debug、info、warn、error]
跨異步和并行作業處理和聚合日志條目
如果程序運行正常，日志包或任何包沒有也不應該有使程序崩潰的權限。任何中間件或庫都應該遵循 throw/catch 模式，并有機會讓調用者捕獲所有拋出的異常。這也是在應用程序中遵循的一個很好的模式，當您構建為應用程序的各個部分以及可能的其他應用程序提供支持的基礎和包時，它們永遠不應該直接使應用程序崩潰。相反，他們應該拋出一個致命的異常，讓程序來處理。我認為這也解決了 Marcus 的一些觀點，因為它可以在未被發現時立即提醒呼叫者，這是致命的崩潰。
在大多數情況下，我可以直接在 Go 中利用 log.Fatal 來實現直接面向用戶的 cli 工具，我認為這是它真正想要的簡單性。我認為作為處理跨包致命錯誤的長期方法沒有什么意義。
- 2 回答
- 0 關注
- 208 瀏覽
添加回答
舉報
0/150
提交
取消