PHP 网站的错误处理

Question

有人可以指导我如何实现以及应该在什么阶段添加错误处理代码的正确方向吗？

网站：
社交网络，如 linkedin。平台是MySql和codeignitor PHP。 要求： 3 种错误情况：

1. 前端类似 http 代码。在这种情况下，用户将被重定向到标准消息页面。 DB 没有什么可捕获的。

2. 第二种情况是后端错误，例如服务器耗时过长、写入数据库时​​出错、其他数据库问题、代码爆炸等。预计在所有这些情况下，用户只会看到一个错误消息框，提示“有人已被已通知，请稍后重试”。与 facebook 上的情况类似，只是 facebook 根据错误类型有不同的错误文本。第二种

3. 第三种错误类型与会话相关：Cookie 在会话期间被中断并发生超时，在这种情况下会显示请登录消息窗口。

我现在的问题是：

1. 要捕获案例 2 中的所有各种错误，是否可以在开发过程中同时完成，还是开发人员必须返回并添加在项目结束时在代码中的每个入口点捕获错误，这可能是数百万行代码？

2. 我的团队告诉我，在整个开发完成之前，他们并不知道情况 2 中可能发生错误的所有可能情况。但我认为无论如何，错误处理代码都是通用的。唯一除了代码之外的是我们想要捕获的错误类别的错误捕获子句以及要显示的错误消息（如果不同）可以随时添加，但底层错误代码是相同的，因此甚至可以在开发开始之前编写？< /p>

3. 我如何找到所有可能的情况或捕获所有可能的情况，在情况 2 中可能会发生错误，其中可能有数百个用例在任何级别上发生爆炸或数据库读/写错误等。我们是否需要单独的每个代码或通用代码捕获所有？

我的开发人员也是新人，我也是，所以我认为没有人完全确定何时以及如何处理网站上的错误。在系统后端，当发生错误时，将向管理员发送一封电子邮件，我正在构建一个错误跟踪系统，以便我们可以在后端自动跟踪问题的状态、类型、注释等。

Answer 1

1.要捕获属于情况2的所有各种错误，是否可以在开发过程中同时完成，还是开发人员必须返回并在项目结束时的每个入口点添加错误捕获在可能有数百万行代码的代码中？

两者都有，但通常只是在开发过程中需要。实际上，考虑每行代码可能会产生哪些类型的错误（尤其是从外部或数据库源获取数据时）非常重要，因此您需要在每个步骤中考虑所有这些错误。为了帮助在一切就绪之后插入特殊情况处理，这是主 错误处理功能开始发挥作用。只需注意哪些错误级别永远不会触发您的自定义错误处理。您可能还对 Exception 类感兴趣。同样，为了通过仅在更少的位置进行更新来更轻松地插入特殊情况处理，请将 Exception 类扩展为您自己的特殊错误对象。

2.我的团队告诉我，在整个开发完成之前，他们并不知道情况 2 中可能发生错误的所有可能情况。但我认为无论如何，错误处理代码都是通用的。唯一除了代码之外的是我们想要捕获的错误类别的错误捕获子句以及要显示的错误消息（如果不同）可以随时添加，但底层错误代码是相同的，因此甚至可以在开发开始之前编写？< /p>

与#1 类似。恕我直言，你是对的。在某些情况下，他们也是如此。一个开发人员实际上无法知道其他开发人员的代码会生成什么类型​​的错误，直到他们看到代码或掌握其最终文档。

3.如何找到所有可能的情况或捕获所有可能的情况，在情况 2 中可能会发生错误，其中可能有数百个用例在任何级别上发生爆炸或数据库读/写错误等。我们是否这样做需要为每个单独的代码还是一个通用的代码来捕获所有内容？

再次离开问题#1，使用自定义错误处理函数或扩展 Exception 类（甚至制作单独的类来处理数据库 try/catch 与文件访问 try/catch 等），这应该会有很大帮助。假设您发现数据库可能会吐出一个新的可能错误。如果您已经将连接和查询函数封装在 try/catch 块中，则只需在扩展的 Exception 类中添加处理脚本，而不用在数据库函数所在的任何位置添加处理脚本。例如，您可以选择对所有数据库连接执行类似的操作。在这种情况下，DB_Exception 是 Exception 的扩展版本，它本身可以执行任意数量的故障排除任务：

function db_connect() {
    $MySQLi = new mysqli(DB_HOST, DB_USERNAME, DB_PW, DB_NAME, DB_PORT, DB_SOCKET);
    if ($MySQLi->connect_error) throw new DB_Exception($MySQLi->connect_error);
    if ($MySQLi->error) throw new DB_Exception($MySQLi->error);
    return $MySQLi;
    }

try {$MySQLi = db_connect();}
catch (DB_Exception $e) {if (!$e->is_fixed_now) die($e->special_message);}

您还可以拥有扩展的 Exception code> 类引用由 $code 构造参数枚举的一组预设响应。但是，您确实不应该尝试对您可能遇到的每个可能出现的数据库错误应用特殊的错误处理。在大多数情况下，只需获取 MySQL 错误文本（无论是什么）并将其转发给您的管理员，这样效率更高，负担也更轻。

至于您向用户显示的文本，最好始终保持简单且信息丰富，同时绝对不透露网站的内部运作情况。示例：您的数据库服务器崩溃或有人错误地设置了文件权限：您应该告诉用户的是“抱歉，技术困难，此特定内容目前不可用，我们的工作人员已通知，请稍后再试。如果紧急电子邮件 < a href="/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="afdcc0efdcc081ccc0c2">[电子邮件受保护] 或致电 555-1212 联系支持人员。”。您还可以根据 Exception $code 参数执行预设消息，与上面相同，但在发生站点攻击时不提供任何帮助。

另外，“在系统后端，当发生错误时，将向管理员发送电子邮件”实际上并不是一个好主意。用户可能只是坐在那里一遍又一遍地点击刷新，直到它神奇地再次开始工作。您很容易陷入电子邮件风暴。一种可能的解决方案是运行 10 分钟的 cron 作业检查以查看过去 10 分钟内错误日志是否已修改，然后通过电子邮件发送新日志条目的摘要。或者，如果您有故障单系统，则仅当该主题的打开单不存在时，才让错误脚本打开一个故障单系统。

Answer 2

1. 应为您期望生成的 HTTP 错误提供适当的错误页面。这些页面应提供有关错误内容的最少数据，并为用户指示适当的重试/后续操作。多一个返回安全区域的链接通常是合适的。
2. 完整的列表将随着开发的进展而公布。这对于任何施工过程都是正常的。代码中无法纠正的任何操作都应由页面生成代码处理。这些可以通过记录并生成适当的 HTTP 错误页面来处理（已在处理 1 中完成）。按类而不是特定错误条件处理错误是合适的。实际的错误情况不应报告给用户，除非用户可以自行更正。
3. 对所有错误使用通用捕获代码并按错误类别进行响应。在许多/大多数情况下，您将希望在错误日志中生成堆栈跟踪。生成适当的 HTTP 错误代码以供显示。查看 HTTP 规范以了解要使用的适当 HTTP 响应。
4. 表单验证是一个单独的类别，应在输入验证期间适当处理。这应该会导致重新显示页面并嵌入适当的错误消息。