1、封裝錯誤error，使其記錄錯誤檔名稱、檔案路徑、行數、操作、錯誤資訊等相關資訊。
//封裝錯誤型別，myerror 型別記錄了檔案，行號，相關的錯誤資訊
type myerror struct
//patherror 除了底層錯誤外還提供了使用哪個檔案，執行哪個操作等相關資訊。
type patherror struct
func (e *myerror) error() string
func (e *patherror) error() string
func fn() error
// use x
}
比如一些網路連線超時的錯誤，可以斷言這種錯誤型別，然後**控制重試操作。
4、將錯誤資訊一層一層的往上打，而不是只簡單返回錯誤error
反例：
func authenticaterequest(r *request) error
return nil
}
正例：
func authenticaterequest(r *request) error
return nil
}
使用這兩個函式，我們現在可以給任何錯誤新增相關資訊，並且在我們需要檢視底層錯誤型別的時候可以解包檢視。下面的例子是讀取檔案內容到記憶體的函式。
func readfile(path string) (byte, error)
defer f.close()
buf, err := ioutil.readall(f)
if err != nil
return buf, nil
}
could not read config: open failed: open /users/dfc/.settings.xml: no such file or directory優雅處理段錯誤
摘要 某些程序在結束前必須要處理一些額外的過程才能結束，尤其是資料儲存的模組，程序停止前為保證資料的完整性可能要做一些事情，如果發生段錯誤，這時就需要先截獲se 訊號，處理完後再讓程式出core 一般程序收到段錯誤訊號預設是dump core檔案然後退出，但有些程序在退出時需要處理額外的過程才能結束...
如何優雅的捕獲錯誤
之前的經常會出現這樣的 邏輯 假設這是乙個api介面呼叫 function userinfo code 000 3000 在頁面載入呼叫這個函式 async function getuserinfo catch error async function usecaptured asyncfunc c...
如何優雅的處理Restful
最近公司搭建的專案，前端反映後端返回格式不統一的問題，因此引發小編的思考，如何能夠優雅的處理返回值格式呢？在度娘中仔細研讀了一番，決定總結一下，於是乎此文便誕生了。首先，大家都會思考為什麼要做統一格式處理呢？現階段的開發模式多以前後端分離形式存在，前後端開發人員需要通過大量 api 來進行資料互動，...