12. Error x Error Handling x Exception

前情提要：

• 程序码的错误 => 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，以便快速掌握程序出错的原因，或在日後有迹可循。