閱讀(22.2k) 書簽贊(0) 我要糾錯

Go 網(wǎng)站錯誤處理

2022-05-13 16:58 更新

我們的Web應(yīng)用一旦上線之后，那么各種錯誤出現(xiàn)的概率都有，Web應(yīng)用日常運行中可能出現(xiàn)多種錯誤，具體如下所示：

數(shù)據(jù)庫錯誤：指與訪問數(shù)據(jù)庫服務(wù)器或數(shù)據(jù)相關(guān)的錯誤。例如，以下可能出現(xiàn)的一些數(shù)據(jù)庫錯誤。
- 連接錯誤：這一類錯誤可能是數(shù)據(jù)庫服務(wù)器網(wǎng)絡(luò)斷開、用戶名密碼不正確、或者數(shù)據(jù)庫不存在。
- 查詢錯誤：使用的SQL非法導(dǎo)致錯誤，這樣子SQL錯誤如果程序經(jīng)過嚴格的測試應(yīng)該可以避免。
- 數(shù)據(jù)錯誤：數(shù)據(jù)庫中的約束沖突，例如一個唯一字段中插入一條重復(fù)主鍵的值就會報錯，但是如果你的應(yīng)用程序在上線之前經(jīng)過了嚴格的測試也是可以避免這類問題。
應(yīng)用運行時錯誤：這類錯誤范圍很廣，涵蓋了代碼中出現(xiàn)的幾乎所有錯誤。可能的應(yīng)用錯誤的情況如下：
- 文件系統(tǒng)和權(quán)限：應(yīng)用讀取不存在的文件，或者讀取沒有權(quán)限的文件、或者寫入一個不允許寫入的文件，這些都會導(dǎo)致一個錯誤。應(yīng)用讀取的文件如果格式不正確也會報錯，例如配置文件應(yīng)該是ini的配置格式，而設(shè)置成了json格式就會報錯。
- 第三方應(yīng)用：如果我們的應(yīng)用程序耦合了其他第三方接口程序，例如應(yīng)用程序發(fā)表文章之后自動調(diào)用接發(fā)微博的接口，所以這個接口必須正常運行才能完成我們發(fā)表一篇文章的功能。
HTTP錯誤：這些錯誤是根據(jù)用戶的請求出現(xiàn)的錯誤，最常見的就是404錯誤。雖然可能會出現(xiàn)很多不同的錯誤，但其中比較常見的錯誤還有401未授權(quán)錯誤(需要認證才能訪問的資源)、403禁止錯誤(不允許用戶訪問的資源)和503錯誤(程序內(nèi)部出錯)。
操作系統(tǒng)出錯：這類錯誤都是由于應(yīng)用程序上的操作系統(tǒng)出現(xiàn)錯誤引起的，主要有操作系統(tǒng)的資源被分配完了，導(dǎo)致死機，還有操作系統(tǒng)的磁盤滿了，導(dǎo)致無法寫入，這樣就會引起很多錯誤。
網(wǎng)絡(luò)出錯：指兩方面的錯誤，一方面是用戶請求應(yīng)用程序的時候出現(xiàn)網(wǎng)絡(luò)斷開，這樣就導(dǎo)致連接中斷，這種錯誤不會造成應(yīng)用程序的崩潰，但是會影響用戶訪問的效果；另一方面是應(yīng)用程序讀取其他網(wǎng)絡(luò)上的數(shù)據(jù)，其他網(wǎng)絡(luò)斷開會導(dǎo)致讀取失敗，這種需要對應(yīng)用程序做有效的測試，能夠避免這類問題出現(xiàn)的情況下程序崩潰。

錯誤處理的目標

在實現(xiàn)錯誤處理之前，我們必須明確錯誤處理想要達到的目標是什么，錯誤處理系統(tǒng)應(yīng)該完成以下工作：

通知訪問用戶出現(xiàn)錯誤了：不論出現(xiàn)的是一個系統(tǒng)錯誤還是用戶錯誤，用戶都應(yīng)當知道Web應(yīng)用出了問題，用戶的這次請求無法正確的完成了。例如，對于用戶的錯誤請求，我們顯示一個統(tǒng)一的錯誤頁面(404.html)。出現(xiàn)系統(tǒng)錯誤時，我們通過自定義的錯誤頁面顯示系統(tǒng)暫時不可用之類的錯誤頁面(error.html)。
記錄錯誤：系統(tǒng)出現(xiàn)錯誤，一般就是我們調(diào)用函數(shù)的時候返回err不為nil的情況，可以使用前面小節(jié)介紹的日志系統(tǒng)記錄到日志文件。如果是一些致命錯誤，則通過郵件通知系統(tǒng)管理員。一般404之類的錯誤不需要發(fā)送郵件，只需要記錄到日志系統(tǒng)。
回滾當前的請求操作：如果一個用戶請求過程中出現(xiàn)了一個服務(wù)器錯誤，那么已完成的操作需要回滾。下面來看一個例子：一個系統(tǒng)將用戶遞交的表單保存到數(shù)據(jù)庫，并將這個數(shù)據(jù)遞交到一個第三方服務(wù)器，但是第三方服務(wù)器掛了，這就導(dǎo)致一個錯誤，那么先前存儲到數(shù)據(jù)庫的表單數(shù)據(jù)應(yīng)該刪除(應(yīng)告知無效)，而且應(yīng)該通知用戶系統(tǒng)出現(xiàn)錯誤了。
保證現(xiàn)有程序可運行可服務(wù)：我們知道沒有人能保證程序一定能夠一直正常的運行著，萬一哪一天程序崩潰了，那么我們就需要記錄錯誤，然后立刻讓程序重新運行起來，讓程序繼續(xù)提供服務(wù)，然后再通知系統(tǒng)管理員，通過日志等找出問題。

如何處理錯誤

錯誤處理其實我們已經(jīng)在十一章第一小節(jié)里面有過介紹如何設(shè)計錯誤處理，這里我們再從一個例子詳細的講解一下，如何來處理不同的錯誤：

通知用戶出現(xiàn)錯誤：

通知用戶在訪問頁面的時候我們可以有兩種錯誤：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>系統(tǒng)錯誤頁面</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>系統(tǒng)暫時不可用!</h1>
                <p>{{.ErrorInfo}}</p>
            </div>
        </div><!--/span-->
    </div>
</div>
</body>
</html>

404的錯誤處理邏輯，如果是系統(tǒng)的錯誤也是類似的操作，同時我們看到在：

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)  //執(zhí)行模板的merger操作
}

func SystemError(w http.ResponseWriter, r *http.Request) {
    log.Critical("系統(tǒng)錯誤")   //系統(tǒng)錯誤觸發(fā)了Critical，那么不僅會記錄日志還會發(fā)送郵件
    t, _ = t.ParseFiles("tmpl/error.html", nil)  //解析模板文件
    ErrorInfo := "系統(tǒng)暫時不可用" //獲取當前用戶信息
    t.Execute(w, ErrorInfo)  //執(zhí)行模板的merger操作
}

如何處理異常

我們知道在很多其他語言中有try...catch關(guān)鍵詞，用來捕獲異常情況，但是其實很多錯誤都是可以預(yù)期發(fā)生的，而不需要異常處理，應(yīng)該當做錯誤來處理，這也是為什么Go語言采用了函數(shù)返回錯誤的設(shè)計，這些函數(shù)不會panic，例如如果一個文件找不到，os.Open返回一個錯誤，它不會panic；如果你向一個中斷的網(wǎng)絡(luò)連接寫數(shù)據(jù)，net.Conn系列類型的Write函數(shù)返回一個錯誤，它們不會panic。這些狀態(tài)在這樣的程序里都是可以預(yù)期的。你知道這些操作可能會失敗，因為設(shè)計者已經(jīng)用返回錯誤清楚地表明了這一點。這就是上面所講的可以預(yù)期發(fā)生的錯誤。

但是還有一種情況，有一些操作幾乎不可能失敗，而且在一些特定的情況下也沒有辦法返回錯誤，也無法繼續(xù)執(zhí)行，這樣情況就應(yīng)該panic。舉個例子：如果一個程序計算x[j]，但是j越界了，這部分代碼就會導(dǎo)致panic，像這樣的一個不可預(yù)期嚴重錯誤就會引起panic，在默認情況下它會殺掉進程，它允許一個正在運行這部分代碼的goroutine從發(fā)生錯誤的panic中恢復(fù)運行，發(fā)生panic之后，這部分代碼后面的函數(shù)和代碼都不會繼續(xù)執(zhí)行，這是Go特意這樣設(shè)計的，因為要區(qū)別于錯誤和異常，panic其實就是異常處理。如下代碼，我們期望通過uid來獲取User中的username信息，但是如果uid越界了就會拋出異常，這個時候如果我們沒有recover機制，進程就會被殺死，從而導(dǎo)致程序不可服務(wù)。因此為了程序的健壯性，在一些地方需要建立recover機制。

func GetUser(uid int) (username string) {
    defer func() {
        if x := recover(); x != nil {
            username = ""
        }
    }()

    username = User[uid]
    return
}

上面介紹了錯誤和異常的區(qū)別，那么我們在開發(fā)程序的時候如何來設(shè)計呢？規(guī)則很簡單：如果你定義的函數(shù)有可能失敗，它就應(yīng)該返回一個錯誤。當我調(diào)用其他package的函數(shù)時，如果這個函數(shù)實現(xiàn)的很好，我不需要擔心它會panic，除非有真正的異常情況發(fā)生，即使那樣也不應(yīng)該是我去處理它。而panic和recover是針對自己開發(fā)package里面實現(xiàn)的邏輯，針對一些特殊情況來設(shè)計。

小結(jié)

本小節(jié)總結(jié)了當我們的Web應(yīng)用部署之后如何處理各種錯誤：網(wǎng)絡(luò)錯誤、數(shù)據(jù)庫錯誤、操作系統(tǒng)錯誤等，當錯誤發(fā)生時，我們的程序如何來正確處理：顯示友好的出錯界面、回滾操作、記錄日志、通知管理員等操作，最后介紹了如何來正確處理錯誤和異常。一般的程序中錯誤和異常很容易混淆的，但是在Go中錯誤和異常是有明顯的區(qū)分，所以告訴我們在程序設(shè)計中處理錯誤和異常應(yīng)該遵循怎么樣的原則。

以上內(nèi)容是否對您有幫助：

← Go 應(yīng)用日志

Go 應(yīng)用部署 →

寫筆記

我要補充