前情提要：

• 程式碼的錯誤 => Bug
• 操作失敗（但程式碼是正確的）=> Error

昨天有提到過什麼是 Bug 以及如何除錯，今天要討論的是 Error。

Error 來自我們無法掌控的外部狀況，例如使用者、伺服器、資料庫設定等等，導致程式碼雖然正確，但無法正常運作。

當 Error 發生的時候程式碼便無法運行下去，為了避免程式碼停止運作，所以我們要處理它，讓程式碼可以跟 yoyodiy 一樣繞過去，或是太過嚴重，要叫工程師快點來處理。

面對 Error

1. 直接處理：
   從 log 找到可以處理的錯誤訊息, eg. 找不到檔案, network 問題

2. 不處理：
   直接把錯誤訊息丟給客戶端。例如：

• 權限錯誤 => 401、403
• 客戶操作不當的錯誤 ⇒ 提交格式錯誤、404
• 可以由客戶端解決的操作問題 ⇒ 503、429

當然我們還是會加上錯誤頁。

3. 直接崩潰：
   屬於 bug 類，可以 log 後建議直接 crash，等待修復

4. 無法處理：
   暫時無法辦法處理的錯誤，用 log 記錄下來追蹤

預防 Error

剛剛提到有些可以繞過去，有些沒辦法。
其實並不是繞過去，而設置一個 Error 守門員，讓錯誤提早被擋下來。

檢查可預期的會導致 Error 的狀況

舉例來說，某個函式的參數必須要接收數字，但使用者傳入字串，這樣的錯誤是可以透過檢查來避免的。
我們也可以用 if 加其他輔助方法來檢查，也可以用 Exception 制定系統級別的錯誤分類。

哪裡要檢查
可能會產生 Error 的地方，或是說從其他地方接資料過來都要加一層。

拋出 Error

錯誤訊息紀錄了許多機密資料，專屬於內部開發人員使用，因此我們要極力避免向使用者拋出錯誤。

最基本的，我們應該設定不同的 .env 檔，在上線產品的版本關閉 DEBUG，避免對使用者直接拋出錯誤。

APP_DEBUG = false

我們也應該區別使用者與開發者的錯誤訊息與代碼，因為一般使用者看到開發者錯誤訊息也不能幫你修好程式，還會被有心人士猜到系統設計，增加被駭入的風險。

建議對使用者拋出 400、500 等通用錯誤代碼，而不是 401、402、403、404 這種會洩漏系統設計的錯誤代碼。

使用者其實不需要知道這麼多。

我們也會在拋出 Error 時設定即時通知並紀錄 log，以便快速掌握程式出錯的原因，或在日後有跡可循。