Php 总是在更高级别的对象中捕获异常是一种好的做法吗？

随着项目变得越来越大，我对应该抛出什么类型的异常以及应该捕获它们的位置感到有点困惑，例如，如何组织内部异常和应该向最终用户显示的异常消息。为了避免混淆，始终捕获更高级别对象中的异常是最佳实践吗

举个例子：如果我有一个数据库类，它在数据库中插入了一行，这个类被另一个处理数据的对象调用，而这个数据处理对象又被一个控制器调用，那么从处理类中的数据库类捕获错误（可能是这样的）是否正确是否重试要在控制器类中捕获的错误？或者，在数据库类中抛出的错误是否可以在控制器类中捕获

此外，如果处理类中的一个方法被同一类中的另一个方法调用，并且第一个方法抛出错误，那么在同一个类中捕获异常可以吗？还是应该推迟到调用它的更高级别的类

关于如何在具有多个级别的类的大型项目中构造和组织异常，还有其他技巧吗

在异常事件中应该抛出异常，即，如果出现严重错误，代码无法按原样继续。例如，数据库已关闭，远程服务未响应，接收到格式严重错误的输入

如果捕获到异常，您需要知道如何处理它。当引发异常时，表示应用程序处于严重错误状态。如果捕获到异常，您应该对如何从此错误状态继续进行有一个认真的计划。如果你没有计划，那么抓住它是没有意义的。如果数据库关闭，您可能希望停止该程序。另一方面，如果远程HTTP请求生成404响应，并且HTTP处理程序将其作为异常抛出，则您可能能够容忍该错误并继续（取决于该请求的用途）

原始异常消息不应显示给最终用户。需要记录异常，但是最终用户应该只看到一条通用的尼斯“Oops，出了问题，也许你想试试X…”消息。这不是特定于例外情况，它只是良好的用户体验设计

---

我喜欢将异常视为可能中断正常程序流的预期事件，但要以有序和可控的方式。 异常处理的任务是处理这种情况，并以程序状态保持有效且应用程序可以继续的方式解决它

因此，您应该在调用层次结构的第一个位置添加异常处理，在那里您实际上能够解决这种情况。 这可能包括清理以前打开的、现在不再需要的资源、记录事件或向用户提供反馈

在您的示例中，我可能会将处理逻辑留给控制器。 数据库通常没有足够的上下文来描述刚刚发生的事情以及如何处理特定条件，因为这些都取决于调用数据库的上下文。 另一方面，您的控制器应该具有所有上下文信息，并且应该非常清楚程序刚刚尝试执行的操作。 它也可能更适合解决问题，例如向用户显示一般错误消息，并可能向管理员发送详细的错误报告

有时，您还需要在中间级别捕获异常，进行一些清理（如关闭流或回滚某些操作），然后重新引发异常，因为您知道您只解决了部分问题

---

总而言之，一般建议是考虑需要采取哪些措施来解决此类异常事件，然后在容易采取这些措施的地方实施错误处理。

1。那么，下一个级别的课程是否应该进行捕获？或者最佳实践在哪里？2.日志记录是在Catch块中完成的，还是在抛出时完成的？1。应该在适当的地方这样做。您可能根本不想捕获数据库错误，或者在最高级别捕获，然后停止所有操作。触发请求并准备处理失败的人应捕获失败的HTTP请求。把“下一节课”作为一个严格的规则是不现实的，因为你甚至无法预测某个东西会发出多少次子调用。2.视情况而定。如果这是一个不值得记录的预期异常（例如HTTP失败），请不要这样做。如果是严重的所有代码暂停异常，请记录。总是在被抓住的地方。