前言

剛開始寫程式時，看到紅字很容易緊張。

很多人的第一反應會是：複製錯誤訊息去搜尋，或是直接問人「這是什麼問題」。

搜尋和問人都沒有錯，但在那之前，我覺得可以先做一件事：把錯誤訊息完整讀完。

錯誤訊息通常不是敵人，它其實是在告訴你程式壞在哪裡。

先看錯誤類型

錯誤訊息通常會先告訴你錯誤類型。

例如 C# 常見的：

1
NullReferenceException

這代表你正在操作一個 null 物件。

或是：

1
IndexOutOfRangeException

這通常代表你存取了陣列或集合不存在的位置。

先知道錯誤類型，就能先縮小問題範圍。

再看錯誤位置

錯誤訊息通常也會附上檔案名稱和行數。

例如：

1
at UserService.GetUserName(Int32 userId) in UserService.cs:line 42

這句話的意思是，錯誤發生在 UserService.cs 的第 42 行。

這時候不要只盯著最後一行，也要往上看呼叫堆疊。因為真正的問題有時候不是爆掉的那一行，而是前面傳進來的資料已經不對。

看懂「發生什麼」和「在哪裡發生」

讀錯誤訊息時，可以先回答兩個問題：

  • 發生了什麼錯誤？
  • 錯誤在哪個檔案、哪一行發生？

如果這兩個問題都回答得出來，除錯就已經前進一大步。

接著再問：

  • 這一行用了哪些變數？
  • 哪個變數可能是 null？
  • 哪個資料可能不符合預期？
  • 這個值是從哪裡傳進來的？

這樣會比盲目修改有效很多。

不要只看最後一段

很多錯誤訊息很長，看起來很可怕。

但長不代表都要讀懂。

可以先找這幾個重點：

  • 錯誤類型
  • 自己專案的檔案名稱
  • 第一個出現在自己程式碼裡的行數
  • exception message

框架內部的堆疊資訊可以先略過，等需要深入追查時再看。

結語

除錯的第一步不是亂改程式，而是先理解錯誤訊息。

我現在看到錯誤時，會先問自己：

  • 它說的錯誤類型是什麼？
  • 它指向哪個檔案和行數？
  • 哪個變數或資料最可疑？
  • 這個錯誤是原因，還是結果？

錯誤訊息讀久了，你會慢慢發現它其實很誠實，只是講話有時候不太親切。