go語言1.13 go語言117

Golang 中更好的錯誤處理：理論和實踐技巧

云和安全管理服務(wù)專家新鈦云服 張春翻譯

成都創(chuàng)新互聯(lián)公司致力于成都網(wǎng)站設(shè)計、做網(wǎng)站,成都網(wǎng)站設(shè)計,集團網(wǎng)站建設(shè)等服務(wù)標(biāo)準(zhǔn)化，推過標(biāo)準(zhǔn)化降低中小企業(yè)的建站的成本，并持續(xù)提升建站的定制化服務(wù)水平進(jìn)行質(zhì)量交付，讓企業(yè)網(wǎng)站從市場競爭中脫穎而出。 選擇成都創(chuàng)新互聯(lián)公司，就選擇了安全、穩(wěn)定、美觀的網(wǎng)站建設(shè)服務(wù)！

這種方法有幾個缺點。首先，它可以對程序員隱藏錯誤處理路徑，特別是在捕獲異常不是強制性的情況下，例如在 Python 中。即使在具有必須處理的 Java 風(fēng)格的檢查異常的語言中，如果在與原始調(diào)用不同的級別上處理錯誤，也并不總是很明顯錯誤是從哪里引發(fā)的。

我們都見過長長的代碼塊包裝在一個 try-catch 塊中。在這種情況下，catch 塊實際上充當(dāng) goto 語句，這通常被認(rèn)為是有害的（奇怪的是，C 中的關(guān)鍵字被認(rèn)為可以接受的少數(shù)用例之一是錯誤后清理，因為該語言沒有 Golang- 樣式延遲語句）。

如果你確實從源頭捕獲異常，你會得到一個不太優(yōu)雅的 Go 錯誤模式版本。這可能會解決混淆代碼的問題，但會遇到另一個問題：性能。在諸如 Java 之類的語言中，拋出異?？赡鼙群瘮?shù)的常規(guī)返回慢數(shù)百倍。

Java 中最大的性能成本是由打印異常的堆棧跟蹤造成的，這是昂貴的，因為運行的程序必須檢查編譯它的源代碼 。僅僅進(jìn)入一個 try 塊也不是空閑的，因為需要保存 CPU 內(nèi)存寄存器的先前狀態(tài)，因為它們可能需要在拋出異常的情況下恢復(fù)。

如果您將異常視為通常不會發(fā)生的異常情況，那么異常的缺點并不重要。這可能是傳統(tǒng)的單體應(yīng)用程序的情況，其中大部分代碼庫不必進(jìn)行網(wǎng)絡(luò)調(diào)用——一個操作格式良好的數(shù)據(jù)的函數(shù)不太可能遇到錯誤（除了錯誤的情況）。一旦您在代碼中添加 I/O，無錯誤代碼的夢想就會破滅：您可以忽略錯誤，但不能假裝它們不存在！

try {

doSometing()

} catch (IOException e) {

// ignore it

}

與大多數(shù)其他編程語言不同，Golang 接受錯誤是不可避免的。 如果在單體架構(gòu)時代還不是這樣，那么在今天的模塊化后端服務(wù)中，服務(wù)通常和外部 API 調(diào)用、數(shù)據(jù)庫讀取和寫入以及與其他服務(wù)通信 。

以上所有方法都可能失敗，解析或驗證從它們接收到的數(shù)據(jù)（通常在無模式 JSON 中）也可能失敗。Golang 使可以從這些調(diào)用返回的錯誤顯式化，與普通返回值的等級相同。從函數(shù)調(diào)用返回多個值的能力支持這一點，這在大多數(shù)語言中通常是不可能的。Golang 的錯誤處理系統(tǒng)不僅僅是一種語言怪癖，它是一種將錯誤視為替代返回值的完全不同的方式！

重復(fù) if err != nil

對 Go 錯誤處理的一個常見批評是被迫重復(fù)以下代碼塊：

res, err := doSomething()

if err != nil {

// Handle error

}

對于新用戶來說，這可能會覺得沒用而且浪費行數(shù)：在其他語言中需要 3 行的函數(shù)很可能會增長到 12 行 ：

這么多行代碼！這么低效！如果您認(rèn)為上述內(nèi)容不優(yōu)雅或浪費代碼，您可能忽略了我們檢查代碼中的錯誤的全部原因：我們需要能夠以不同的方式處理它們！對 API 或數(shù)據(jù)庫的調(diào)用可能會被重試。

有時事件的順序很重要：調(diào)用外部 API 之前發(fā)生的錯誤可能不是什么大問題（因為數(shù)據(jù)從未通過發(fā)送），而 API 調(diào)用和寫入本地數(shù)據(jù)庫之間的錯誤可能需要立即注意，因為 這可能意味著系統(tǒng)最終處于不一致的狀態(tài)。即使我們只想將錯誤傳播給調(diào)用者，我們也可能希望用失敗的解釋來包裝它們，或者為每個錯誤返回一個自定義錯誤類型。

并非所有錯誤都是相同的，并且向調(diào)用者返回適當(dāng)?shù)腻e誤是 API 設(shè)計的重要部分，無論是對于內(nèi)部包還是 REST API 。

不必?fù)?dān)心在你的代碼中重復(fù) if err != nil ——這就是 Go 中的代碼應(yīng)該看起來的樣子。

自定義錯誤類型和錯誤包裝

從導(dǎo)出的方法返回錯誤時，請考慮指定自定義錯誤類型，而不是單獨使用錯誤字符串。字符串在意外代碼中是可以的，但在導(dǎo)出的函數(shù)中，它們成為函數(shù)公共 API 的一部分。更改錯誤字符串將是一項重大更改——如果沒有明確的錯誤類型，需要檢查返回錯誤類型的單元測試將不得不依賴原始字符串值！事實上，基于字符串的錯誤也使得在私有方法中測試不同的錯誤案例變得困難，因此您也應(yīng)該考慮在包中使用它們?；氐藉e誤與異常的爭論，返回錯誤也使代碼比拋出異常更容易測試，因為錯誤只是要檢查的返回值。不需要測試框架或在測試中捕獲異常 。

可以在 database/sql 包中找到簡單自定義錯誤類型的一個很好的示例。它定義了一個導(dǎo)出常量列表，表示包可以返回的錯誤類型，最著名的是 sql.ErrNoRows。雖然從 API 設(shè)計的角度來看，這種特定的錯誤類型有點問題（您可能會爭辯說 API 應(yīng)該返回一個空結(jié)構(gòu)而不是錯誤），但任何需要檢查空行的應(yīng)用程序都可以導(dǎo)入該常量并在代碼中使用它不必?fù)?dān)心錯誤消息本身會改變和破壞代碼。

對于更復(fù)雜的錯誤處理，您可以通過實現(xiàn)返回錯誤字符串的 Error() 方法來定義自定義錯誤類型。自定義錯誤可以包括元數(shù)據(jù)，例如錯誤代碼或原始請求參數(shù)。如果您想表示錯誤類別，它們很有用。DigitalOcean 的本教程展示了如何使用自定義錯誤類型來表示可以重試的一類臨時錯誤。

通常，錯誤會通過將低級錯誤與更高級別的解釋包裝起來，從而在程序的調(diào)用堆棧中傳播。例如，數(shù)據(jù)庫錯誤可能會以下列格式記錄在 API 調(diào)用處理程序中：調(diào)用 CreateUser 端點時出錯：查詢數(shù)據(jù)庫時出錯：pq：檢測到死鎖。這很有用，因為它可以幫助我們跟蹤錯誤在系統(tǒng)中傳播的過程，向我們展示根本原因（數(shù)據(jù)庫事務(wù)引擎中的死鎖）以及它對更廣泛系統(tǒng)的影響（調(diào)用者無法創(chuàng)建新用戶）。

自 Go 1.13 以來，此模式具有特殊的語言支持，并帶有錯誤包裝。通過在創(chuàng)建字符串錯誤時使用 %w 動詞，可以使用 Unwrap() 方法訪問底層錯誤。除了比較錯誤相等性的函數(shù) errors.Is() 和 errors.As() 外，程序還可以獲取包裝錯誤的原始類型或標(biāo)識。這在某些情況下可能很有用，盡管我認(rèn)為在確定如何處理所述錯誤時最好使用頂級錯誤的類型。

Panics

不要 panic()！長時間運行的應(yīng)用程序應(yīng)該優(yōu)雅地處理錯誤而不是panic。即使在無法恢復(fù)的情況下（例如在啟動時驗證配置），最好記錄一個錯誤并優(yōu)雅地退出。panic比錯誤消息更難診斷，并且可能會跳過被推遲的重要關(guān)閉代碼。

Logging

我還想簡要介紹一下日志記錄，因為它是處理錯誤的關(guān)鍵部分。通常你能做的最好的事情就是記錄收到的錯誤并繼續(xù)下一個請求。

除非您正在構(gòu)建簡單的命令行工具或個人項目，否則您的應(yīng)用程序應(yīng)該使用結(jié)構(gòu)化的日志庫，該庫可以為日志添加時間戳，并提供對日志級別的控制。最后一部分特別重要，因為它將允許您突出顯示應(yīng)用程序記錄的所有錯誤和警告。通過幫助將它們與信息級日志分開，這將為您節(jié)省無數(shù)時間。

微服務(wù)架構(gòu)還應(yīng)該在日志行中包含服務(wù)的名稱以及機器實例的名稱。默認(rèn)情況下記錄這些時，程序代碼不必?fù)?dān)心包含它們。您也可以在日志的結(jié)構(gòu)化部分中記錄其他字段，例如收到的錯誤（如果您不想將其嵌入日志消息本身）或有問題的請求或響應(yīng)。只需確保您的日志沒有泄露任何敏感數(shù)據(jù)，例如密碼、API 密鑰或用戶的個人數(shù)據(jù)！

對于日志庫，我過去使用過 logrus 和 zerolog，但您也可以選擇其他結(jié)構(gòu)化日志庫。如果您想了解更多信息，互聯(lián)網(wǎng)上有許多關(guān)于如何使用這些的指南。如果您將應(yīng)用程序部署到云中，您可能需要日志庫上的適配器來根據(jù)您的云平臺的日志 API 格式化日志 - 沒有它，云平臺可能無法檢測到日志級別等某些功能。

如果您在應(yīng)用程序中使用調(diào)試級別日志（默認(rèn)情況下通常不記錄），請確保您的應(yīng)用程序可以輕松更改日志級別，而無需更改代碼。更改日志級別還可以暫時使信息級別甚至警告級別的日志靜音，以防它們突然變得過于嘈雜并開始淹沒錯誤。您可以使用在啟動時檢查以設(shè)置日志級別的環(huán)境變量來實現(xiàn)這一點。

原文：

Go語言安裝與鏡像配置

安裝網(wǎng)址

國內(nèi)鏡像

Go 1.13 及以上（推薦

打開你的終端并執(zhí)行

macOS 或 Linux

或

如果是zsh

請這樣設(shè)置

Windows

打開PowerShell 并執(zhí)行

或者

然后你就可以

深入剖析：一套在 Go 中傳遞、返回、暴露錯誤，便于回查的解決方案

作者：andruzhang，騰訊 IEG 后臺開發(fā)工程師

在后臺開發(fā)中，針對錯誤處理，有三個維度的問題需要解決：

一個面向過程的函數(shù)，在不同的處理過程中需要 handle 不同的錯誤信息；一個面向?qū)ο蟮暮瘮?shù)，針對一個操作所返回的不同類型的錯誤，有可能需要進(jìn)行不同的處理。此外，在遇到錯誤時，也可以使用斷言的方式，快速中止函數(shù)流程，大大提高代碼的可讀性。

在許多高級語言中都提供了 try ... catch 的語法，函數(shù)內(nèi)部可以通過這種方案，實現(xiàn)一個統(tǒng)一的錯誤處理邏輯。而即便是 C 這種 “中級語言” 雖然沒有，但是程序員也可以使用宏定義的方式，來實現(xiàn)某種程度上的錯誤斷言。

但是，對于 Go 的情況就比較尷尬了。

我們先來看斷言，我們的目的是，僅使用一行代碼就能夠檢查錯誤并終止當(dāng)前函數(shù)。由于沒有 throw，沒有宏，如果要實現(xiàn)一行斷言，有兩種方法。

第一種是把 if 的錯誤判斷寫在一行內(nèi)，比如：

第二種方法是借用 panic 函數(shù)，結(jié)合 recover 來實現(xiàn):

這兩種方法都值得商榷。

首先，將 if 寫在同一行內(nèi)的問題有：

至于第二種方法，我們要分情況看；

不過使用 panic 來斷言的方案，雖然在業(yè)務(wù)邏輯中基本上不用，但在測試場景下則是非常常見的。測試嘛，用牛刀有何不可？稍微大一點的系統(tǒng)開銷也沒啥問題。對于 Go 來說，非常熱門的單元測試框架 goconvey 就是使用 panic 機制來實現(xiàn)單元測試中的斷言，用的人都說好。

綜上，在 Go 中，對于業(yè)務(wù)代碼，筆者不建議采用斷言，遇到錯誤的時候建議還是老老實實采用這種格式：

而在單測代碼中，則完全可以大大方方地采用類似于 goconvey 之類基于 panic 機制的斷言。

眾所周知 Go 是沒有 try ... catch 的，而且從官方的態(tài)度來看，短時間內(nèi)也沒有考慮的計劃。但程序員有這個需求呀。筆者采用的方法，是將需要返回的 err 變量在函數(shù)內(nèi)部全局化，然后結(jié)合 defer 統(tǒng)一處理：

這種方案要特別注意變量作用域問題.比如前面的 if err = DoSomething(); err != nil { 行，如果我們將 err = ... 改為 err := ...，那么這一行中的 err 變量和函數(shù)最前面定義的 (err error) 不是同一個變量，因此即便在此處發(fā)生了錯誤，但是在 defer 函數(shù)中無法捕獲到 err 變量了。

在 try ... catch 方面，筆者其實沒有特別好的方法來模擬，即便是上面的方法也有一個很讓人頭疼的問題：defer 寫法導(dǎo)致錯誤處理前置，而正常邏輯后置了，從可讀性的角度來說非常不友好。因此也希望讀者能夠指教。同時還是希望 Go 官方能夠繼續(xù)迭代，支持這種語法。

這一點在 Go 里面，一開始看起來還是比較統(tǒng)一的，這就是 Go 最開始就定義的 error 類型，以系統(tǒng)標(biāo)準(zhǔn)的方式，統(tǒng)一了進(jìn)程內(nèi)函數(shù)級的錯誤返回模式。調(diào)用方使用 if err != nil 的統(tǒng)一模式，來判斷一個調(diào)用是不是成功了。

但是隨著 Go 的逐步推廣，由于 error 接口的高自由度，程序員們對于 “如何判斷該錯誤是什么錯誤” 的時候，出現(xiàn)了分歧。

在 Go 1.13 之前，對于 error 類型的傳遞，有三種常見的模式：

這個流派很簡單，就是將各種錯誤信息直接定義為一個類枚舉值的模式，比如：

當(dāng)遇到相應(yīng)的錯誤信息時，直接返回對應(yīng)的 error 類枚舉值就行了。對于調(diào)用方也非常方便，可以采用 switch - case 來判斷錯誤類型：

個人覺得這種設(shè)計模式本質(zhì)上還是 C error code 模式。

這種流派則是充分使用了 “error 是一個 interface” 的特性，重新自定義一個 error 類型。一方面是用不同的類型來表示不同的錯誤分類，另一方面則能夠?qū)崿F(xiàn)對于同一錯誤類型，能夠給調(diào)用方提供更佳詳盡的信息。舉個例子，我們可以定義多個不同的錯誤類型如下：

對于調(diào)用方，則通過以下代碼來判斷不同的錯誤：

這種模式，一方面可以透傳底層錯誤，另一方面又可以添加自定義的信息。但對于調(diào)用方而言，災(zāi)難在于如果要判斷某一個錯誤的具體類型，只能用 strings.Contains() 來實現(xiàn)，而錯誤的具體描述文字是不可靠的，同一類型的信息可能會有不同的表達(dá)；而在 fmt.Errorf 的過程中，各個業(yè)務(wù)添加的額外信息也可能會有不同的文字，這帶來了極大的不可靠性，提高了模塊之間的耦合度。

在 go 1.13 版本發(fā)布之后，針對 fmt.Errorf 增加了 wraping 功能，并在 errors 包中添加了 Is() 和 As() 函數(shù)。關(guān)于這個模式的原理和使用已經(jīng)有很多文章了，本文就不再贅述。

這個功能，合并并改造了前文的所謂 “== 流派” 和 “fmt.Errorf” 流派，統(tǒng)一使用 errors.Is() 函數(shù)；此外，也算是官方對類型斷言流派的認(rèn)可（專門用 As() 函數(shù)來支持）。

在實際應(yīng)用中，函數(shù)/模塊透傳錯誤時，應(yīng)該采用 Go 的 error wrapping 模式，也就是 fmt.Errorf() 配合 %w 使用，業(yè)務(wù)方可以放心地添加自己的錯誤信息，只要調(diào)用方統(tǒng)一采用 errors.Is() 和 errors.As() 即可。

服務(wù)/系統(tǒng)層面的錯誤信息返回，大部分協(xié)議都可以看成是 code - message 模式或者是其變體：

這種模式的特點是：code 是給程序代碼使用的，代碼判斷這是一個什么類型的錯誤，進(jìn)入相應(yīng)的分支處理；而 message 是給人看的，程序可以以某種形式拋出或者記錄這個錯誤信息，供用戶查看。

在這一層面有什么問題呢？code for computer，message for user，好像挺好的。

但有時候，我們可能會收到用戶/客戶反饋一個問題：“XXX 報錯了，幫忙看看什么問題？”。用戶看不懂我們的錯誤提示嗎？

在筆者的經(jīng)驗中，我們在使用 code - message 機制的時候，特別是業(yè)務(wù)初期，難以避免的是前后端的設(shè)計文案沒能完整地覆蓋所有的錯誤用例，或者是錯誤極其罕見。因此當(dāng)出現(xiàn)錯誤時，提示曖昧不清（甚至是直接提示錯誤信息），導(dǎo)致用戶從錯誤信息中找到解決方案

在這種情況下，盡量覆蓋所有錯誤路徑肯定是最完美的方法。不過在做到這一點之前，碼農(nóng)們往往有下面的解決方案：

既要隱藏信息，又要暴露信息，我可以摔盤子嗎……

這里，筆者從日益普及的短信驗證碼有了個靈感——人的短期記憶對 4 個字符還是比較強的，因此我們可以考慮把錯誤代碼縮短到 4 個字符——不區(qū)分大小寫，因為如果人在記憶時還要記錄大小寫的話，難度會增加不少。

怎么用 4 個字符表示盡量多的數(shù)據(jù)呢？數(shù)字+字母總共有 36 個字符，理論上使用 4 位 36 進(jìn)制可以表示 36x36x36x36 = 1679616 個值。因此我們只要找到一個針對錯誤信息字符串的哈希算法，把輸出值限制在 1679616 范圍內(nèi)就行了。

這里我采用的是 MD5 作為例子。MD5 的輸出是 128 位，理論上我可以取 MD5 的輸出，模 1679616 就可以得到一個簡易的結(jié)果。實際上為了減少除法運算，我采用的是取高 20 位（0xFFFFF）的簡易方式（20 位二進(jìn)制的最大值為 1048575），然后將這個數(shù)字轉(zhuǎn)成 36 進(jìn)制的字符串輸出。

當(dāng)出現(xiàn)異常錯誤時，我們可以將 message 的提示信息如下展示：“未知錯誤，錯誤代碼 30EV，如需協(xié)助，請聯(lián)系 XXX”。順帶一提，30EV 是 "Access denied for user 'db_user'@'127.0.0.1'" 的計算結(jié)果，這樣一來，我就對調(diào)用方隱藏了敏感信息。

至于后臺側(cè)，還是需要實實在在地將這個哈希值和具體的錯誤信息記錄在日志或者其他支持搜索的渠道里。當(dāng)用戶提供該代碼時，可以快速定位。

這種方案的優(yōu)點很明顯：

簡易的錯誤碼生成代碼如下：

當(dāng)然這種方案也有局限性，筆者能想到的是需要注意以下兩點：

此外，筆者需要再強調(diào)的是：在開發(fā)中，針對各種不同的、正式的錯誤用例依然需要完整覆蓋，盡可能通過已有的 code - message 機制將足夠清晰的信息告知主調(diào)方。這種 hashcode 的錯誤代碼生成方法，僅適用于錯誤用例遺漏、或者是快速迭代過程中，用于發(fā)現(xiàn)和調(diào)試遺漏的錯誤用例的臨時方案。

本文題目：go語言1.13 go語言117
網(wǎng)站路徑：http://muchs.cn/article22/hphscc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供手機網(wǎng)站建設(shè)、營銷型網(wǎng)站建設(shè)、網(wǎng)站維護(hù)、商城網(wǎng)站、做網(wǎng)站、品牌網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)