我应该在编写的每种方法中使用错误处理吗

Question

我有两个类，MyFirstClass和MySecondClass。 我在MyFirstClass中创建了MySecondClass对象。

而且如果MySecondClass中发生任何类型的错误，我该如何通过try{}catch(/Exception $e){}处理这些错误。

假设由于以下原因可能会发生错误，

• 数组的未定义索引
• 未定义的变量
• SQL查询异常

样例代码：

class MyFirstClass {

    public function index() {
        try {
            $mySecondClass = new MySecondClass();
            $mySecondClass->sampleMethod();
        } catch(\Exception $e) {
            error_log($e->getMessage(), 0);
            $this->doSomethingElse();
        }
    }
}

我应该在编写的每种方法中使用错误处理吗？ 请分享您的建议。

Answer 1

遍历方法和代码的try / catch / throw / log不是一个好习惯。 考虑到这一点，您应该问以下问题：

您将如何处理该异常？ 如果答案不正确，我想你需要三思。 如果状态由于catch块中的吞咽异常而损坏，则调用堆栈中位于较高位置的某些方法可能会再次引发异常-现在该如何处理该异常？ 同样的周期？ 它将很快导致您陷入更大的混乱。

你可能会保守地要遵循立即捕捉异常的模式，当你真的知道你可以用它做什么（如燕子和SQL超时异常的情况下，重试），你可能也想立刻赶上情况例外，当你想捕捉更多日志中特定于上下文的详细信息。 在那种情况下，捕获并重新抛出新异常，将原始异常包装为内部异常。

简而言之，在应用程序根级别或服务边界级别进行异常处理/记录是一件好事。

话虽如此-在集中位置，您还可以配置如何处理特定类型的异常。 例如 ：

在业务层中作为数据验证的一部分引发的错误请求异常将仅返回400错误请求（对于Web应用程序）

如果异常的类型为SqlException-将具有某些跟踪ID的通用异常抛出给客户端，并将详细的异常记录到eventlog / db / Application Insight等中。

如果业务层中的外部系统有任何异常，请再次将通用异常发送给客户端，并将通知电子邮件发送给提供外部服务的系统。

这些只是几个示例，围绕异常处理的良好实践也隐含地促进了良好的设计。 例如：为什么不采取安全措施确保传递给方法的参数不为null并抛出ArgumentNullException而不是捕获NullReferenceException，然后通过在方法级别使用try / catch / log来捕获参数值。

我在此处发布了有关异常处理和记录良好实践的问题 。 请检查它是否进行了良好的辩论和讨论，并提出了各种建议和良好做法。