通过以下方式搜索 
granam / exception-hierarchy
5.1.0
2021-03-23 17:26 UTC
Requires
- php: >=7.3
Requires (Dev)
- phpunit/phpunit: ~9.0
README
异常层次结构的哲学是“你必须知道”。
了解发生了什么很重要。并且它发生了...
系统失败。发生了异常。
要尽可能详细地描述问题。
实现这一点的最佳方式是保持异常层次结构简洁明了。
- 遵循项目结构。
- 将一个 根异常标记符作为接口。
- 将此接口包含在你产生的 每个 异常中。
- 这样，任何人都可以通过单个捕获在其项目中捕获来自你的项目的异常
- 了解逻辑异常和运行时异常的区别
- 基本区别是逻辑异常可以在编译时检测到（例如，通过IDE），而运行时异常不能 - 它只能在某些数据和环境组合中出现
- 如果确实存在应用程序使用的错误，逻辑异常应该发生
- 该异常告诉您：您使用的东西不好，请修复它
- 运行时异常当然是一切其他的东西
- 这意味着：您的应用程序不如应有的鲁棒 - 修复它或永远忽略
- 就这么简单，界限清晰吗？
- 当然不是
- 但这样您可以捕获所有逻辑异常到 PersistentBugs 文件夹，将运行时异常捕获到 BulletproofFailures 中
简而言之
运行时异常 应该在 外部 出现错误时发生。
逻辑异常 应该在 内部 出现错误时发生。
逻辑和运行时异常的使用示例
您创建了一个带 API 的电子商务。
您的前端应用程序向 API 发送一个新客户的请求
- 电子邮件: dontbotherme
这绝对不是有效的电子邮件。前端检查失败，现在您被迫处理这个失败。
所以在您的代码中某处抛出一些 运行时（如 InvalidEmailFormat）异常。
当然，您的 API 应该捕获此类异常，并返回 400 Bad Request（并返回描述性错误消息）。
在另一种情况下，您的应用程序计算购买的价格，包括折扣券、数量折扣、忠诚度折扣等... 哇，最终价格是负数！
这肯定是一个致命错误，起源于您的应用程序内部。应该抛出 逻辑（如 FinalPriceZeroOrLesser）异常。
当然，API 会捕获该异常并将其转换为响应 500 Server error（并记录该异常以便尽快修复！）。