php - Laravel:在哪里抛出 HTTP 异常

Question

背景

在 PHP/Laravel MVC 应用程序中，响应代码和正文通常由抛出的异常决定。如果抛出 HTTP 异常(继承自 Symfony\Component\HttpKernel\Exception\HttpException)，则会抛出正确的响应代码(在某些情况下是 JSON 响应)。还有其他类型的非 http 相关的异常也可以被抛出。

问题

应该在哪里抛出 HTTP 异常？

• A 只有控制者
• B 任何地方。在应用程序堆栈的深处或浅层。

我应该在 Controller 中捕获我的异常并抛出这些异常的 HTTP 版本吗？还是考虑到 99% 的 MVC 框架应用程序都基于 HTTP 请求 >> 响应生命周期，我是否应该在服务类、存储库或实用程序的任何深处抛出 HTTP 异常？

Answer 1

我的回答并不针对 Laravel，因为我觉得使用框架思维实际上违背了你最初的问题。

始终抛出定制的异常，然后在 Controller 内处理转换。在这种情况下，将其包装在 HttpException 中。这有几个很好的理由:

• 决定将哪些状态代码和消息委托(delegate)给实现(在本例中是与您的框架的集成)。这意味着您可以将代码放在任何框架中并单独处理其错误。
• 您决定需要一个 CLI 命令/工作程序，现在您在服务中抛出的 HttpException 对您的 CLI 命令毫无意义。

本质上考虑一个计算器，它会抛出一个DivisionByZeroException。对于 Controller ，您可以将其包装在 HttpException 400 BAD REQUEST 中并重新抛出。对于 CLI，您的命令可以让异常呈现在屏幕上 Division By Zero。 无论哪种方式，这个决定都不是由您的服务做出的。