golang网站错误处理
我們的Web應用一旦上線之后，那么各種錯誤出現的概率都有，Web應用日常運行中可能出現多種錯誤，具體如下所示：
-
數據庫錯誤：指與訪問數據庫服務器或數據相關的錯誤。例如，以下可能出現的一些數據庫錯誤。
- 連接錯誤：這一類錯誤可能是數據庫服務器網絡斷開、用戶名密碼不正確、或者數據庫不存在。
- 查詢錯誤：使用的SQL非法導致錯誤，這樣子SQL錯誤如果程序經過嚴格的測試應該可以避免。
- 數據錯誤：數據庫中的約束沖突，例如一個唯一字段中插入一條重復主鍵的值就會報錯，但是如果你的應用程序在上線之前經過了嚴格的測試也是可以避免這類問題。
-
應用運行時錯誤：這類錯誤范圍很廣，涵蓋了代碼中出現的幾乎所有錯誤。可能的應用錯誤的情況如下：
- 文件系統和權限：應用讀取不存在的文件，或者讀取沒有權限的文件、或者寫入一個不允許寫入的文件，這些都會導致一個錯誤。應用讀取的文件如果格式不正確也會報錯，例如配置文件應該是ini的配置格式，而設置成了json格式就會報錯。
- 第三方應用：如果我們的應用程序耦合了其他第三方接口程序，例如應用程序發表文章之后自動調用接發微博的接口，所以這個接口必須正常運行才能完成我們發表一篇文章的功能。
-
HTTP錯誤：這些錯誤是根據用戶的請求出現的錯誤，最常見的就是404錯誤。雖然可能會出現很多不同的錯誤，但其中比較常見的錯誤還有401未授權錯誤(需要認證才能訪問的資源)、403禁止錯誤(不允許用戶訪問的資源)和503錯誤(程序內部出錯)。
-
操作系統出錯：這類錯誤都是由于應用程序上的操作系統出現錯誤引起的，主要有操作系統的資源被分配完了，導致死機，還有操作系統的磁盤滿了，導致無法寫入，這樣就會引起很多錯誤。
-
網絡出錯：指兩方面的錯誤，一方面是用戶請求應用程序的時候出現網絡斷開，這樣就導致連接中斷，這種錯誤不會造成應用程序的崩潰，但是會影響用戶訪問的效果；另一方面是應用程序讀取其他網絡上的數據，其他網絡斷開會導致讀取失敗，這種需要對應用程序做有效的測試，能夠避免這類問題出現的情況下程序崩潰。
錯誤處理的目標
在實現錯誤處理之前，我們必須明確錯誤處理想要達到的目標是什么，錯誤處理系統應該完成以下工作：
- 通知訪問用戶出現錯誤了：不論出現的是一個系統錯誤還是用戶錯誤，用戶都應當知道Web應用出了問題，用戶的這次請求無法正確的完成了。例如，對于用戶的錯誤請求，我們顯示一個統一的錯誤頁面(404.html)。出現系統錯誤時，我們通過自定義的錯誤頁面顯示系統暫時不可用之類的錯誤頁面(error.html)。
- 記錄錯誤：系統出現錯誤，一般就是我們調用函數的時候返回err不為nil的情況，可以使用前面小節介紹的日志系統記錄到日志文件。如果是一些致命錯誤，則通過郵件通知系統管理員。一般404之類的錯誤不需要發送郵件，只需要記錄到日志系統。
- 回滾當前的請求操作：如果一個用戶請求過程中出現了一個服務器錯誤，那么已完成的操作需要回滾。下面來看一個例子：一個系統將用戶遞交的表單保存到數據庫，并將這個數據遞交到一個第三方服務器，但是第三方服務器掛了，這就導致一個錯誤，那么先前存儲到數據庫的表單數據應該刪除(應告知無效)，而且應該通知用戶系統出現錯誤了。
- 保證現有程序可運行可服務：我們知道沒有人能保證程序一定能夠一直正常的運行著，萬一哪一天程序崩潰了，那么我們就需要記錄錯誤，然后立刻讓程序重新運行起來，讓程序繼續提供服務，然后再通知系統管理員，通過日志等找出問題。
如何處理錯誤
錯誤處理其實我們已經在十一章第一小節里面有過介紹如何設計錯誤處理，這里我們再從一個例子詳細的講解一下，如何來處理不同的錯誤：
-
通知用戶出現錯誤：
通知用戶在訪問頁面的時候我們可以有兩種錯誤：404.html和error.html，下面分別顯示了錯誤頁面的源碼：
<html lang="en"> <head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><title>找不到頁面</title><meta name="viewport" content="width=device-width, initial-scale=1.0"></head> <body> <div class="container"><div class="row"><div class="span10"><div class="hero-unit"><h1>404!</h1><p>{{.ErrorInfo}}</p></div></div><!--/span--></div> </div> </body> </html>另一個源碼：
<html lang="en"> <head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><title>系統錯誤頁面</title><meta name="viewport" content="width=device-width, initial-scale=1.0"></head> <body> <div class="container"><div class="row"><div class="span10"><div class="hero-unit"><h1>系統暫時不可用!</h1><p>{{.ErrorInfo}}</p></div></div><!--/span--></div> </div> </body> </html>404的錯誤處理邏輯，如果是系統的錯誤也是類似的操作，同時我們看到在：
func (p *MyMux) ServeHTTP(w http.ResponseWriter, r *http.Request) {if r.URL.Path == "/" {sayhelloName(w, r)return}NotFound404(w, r)return }func NotFound404(w http.ResponseWriter, r *http.Request) {log.Error("頁面找不到") //記錄錯誤日志t, _ = t.ParseFiles("tmpl/404.html", nil) //解析模板文件ErrorInfo := "文件找不到" //獲取當前用戶信息t.Execute(w, ErrorInfo) //執行模板的merger操作 }func SystemError(w http.ResponseWriter, r *http.Request) {log.Critical("系統錯誤") //系統錯誤觸發了Critical，那么不僅會記錄日志還會發送郵件t, _ = t.ParseFiles("tmpl/error.html", nil) //解析模板文件ErrorInfo := "系統暫時不可用" //獲取當前用戶信息t.Execute(w, ErrorInfo) //執行模板的merger操作 }
如何處理異常
我們知道在很多其他語言中有try...catch關鍵詞，用來捕獲異常情況，但是其實很多錯誤都是可以預期發生的，而不需要異常處理，應該當做錯誤來處理，這也是為什么Go語言采用了函數返回錯誤的設計，這些函數不會panic，例如如果一個文件找不到，os.Open返回一個錯誤，它不會panic；如果你向一個中斷的網絡連接寫數據，net.Conn系列類型的Write函數返回一個錯誤，它們不會panic。這些狀態在這樣的程序里都是可以預期的。你知道這些操作可能會失敗，因為設計者已經用返回錯誤清楚地表明了這一點。這就是上面所講的可以預期發生的錯誤。
但是還有一種情況，有一些操作幾乎不可能失敗，而且在一些特定的情況下也沒有辦法返回錯誤，也無法繼續執行，這樣情況就應該panic。舉個例子：如果一個程序計算x[j]，但是j越界了，這部分代碼就會導致panic，像這樣的一個不可預期嚴重錯誤就會引起panic，在默認情況下它會殺掉進程，它允許一個正在運行這部分代碼的goroutine從發生錯誤的panic中恢復運行，發生panic之后，這部分代碼后面的函數和代碼都不會繼續執行，這是Go特意這樣設計的，因為要區別于錯誤和異常，panic其實就是異常處理。如下代碼，我們期望通過uid來獲取User中的username信息，但是如果uid越界了就會拋出異常，這個時候如果我們沒有recover機制，進程就會被殺死，從而導致程序不可服務。因此為了程序的健壯性，在一些地方需要建立recover機制。
func GetUser(uid int) (username string) {defer func() {if x := recover(); x != nil {username = ""}}()username = User[uid]return }上面介紹了錯誤和異常的區別，那么我們在開發程序的時候如何來設計呢？規則很簡單：如果你定義的函數有可能失敗，它就應該返回一個錯誤。當我調用其他package的函數時，如果這個函數實現的很好，我不需要擔心它會panic，除非有真正的異常情況發生，即使那樣也不應該是我去處理它。而panic和recover是針對自己開發package里面實現的邏輯，針對一些特殊情況來設計。
《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀總結
以上是生活随笔為你收集整理的golang网站错误处理的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： golang应用日志
- 下一篇： golang应用部署