通过 
搜索
搜索granam / exceptions-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（并记录该异常以便尽快修复）。