是什麼對於一個上線的程式最重要呢？最基本就不要crash，不要處理的資料有錯，所以筆者想先來談談這個部分吧。

系列文前面幾篇會探討，什麼情況下可能會導致發生嚴重錯誤，錯誤的發生有哪些常見的狀況，以及處理的概念。

程式crash時會拋出的訊息：panic 或者 fatal error

眾所知golang是需要事先編譯的程式語言，若編譯期間就知道錯誤，編譯會失敗，我們要討論的是編譯成功之後，程式的執行期間發生的錯誤。

執行中若遇到足以讓程式crash的錯誤，可以看到golang拋出panic 或者fatal error的訊息出來，觀看打印出的trace，可知是以stack的概念，逐層往上拋出，並且告知你在哪裡發生了什麼樣的嚴重錯誤。

所謂的錯誤，在Golang有特別定義的型態，就叫做『error』，『error』在Golang程式裡面的出現和傳遞，是非常稀鬆平常的事情，Golang的設計原則本身也鼓勵開發者斟酌各處可能發生的錯誤，並且好好的處理。

然而執行期間發生的嚴重錯誤，就超乎了『error』的層級和概念，並且會導致程式發生crash。

而這個會crash的錯誤又分為兩種，可復原的，或者不可復原的(程式必crash)。

可復原的嚴重錯誤，在golang裡面定義為『panic』，而不可復原的是『fatal error』。

panic & recover

關於panic的處理策略，可以安排程式在某處接收這樣panic，並且用golang提供的『recover』函式，修復遇到的panic，讓程式不至於crash，當然你也可以選擇不準備recover，那麼當有panic發生時，程式就會crash。

一但發生了crash，程式直接在系統的程序管理上消失得無影無蹤。

下面這是crash時，拋出panic的錯誤訊息
panic 是類型，冒號後面是原因

panic: assignment to entry in nil map

goroutine 9 [running]:
main.testB(0xc000018080, 0x5)

fatal error

另一種錯誤是無法修復的fatal error，錯誤訊息就不會有個『panic:』的前綴，這種狀況比較少見，一但發生就無可救藥，可以拯救panic的recover也無法救這種錯誤，趕緊修改程式或者重啟可能是比較實在的方案。

如下面這種fatal error

fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x2 addr=0xe88a08 pc=0x40c23e]

下篇著重探討panic的部分，fatal error的成因有時候相當複雜和找查困難，甚至跟環境都可能有相關。