在处理自定义 PHP 异常时使用“die()”是一个好习惯吗？答案

【问题标题】：Is it a good practice to use "die()" when dealing with custom PHP Exceptions?在处理自定义 PHP 异常时使用“die()”是一个好习惯吗？
【发布时间】：2012-10-17 04:28:28
【问题描述】：

我在 PHP 中编写了一个自定义异常类：

<?php

class Custom_Exception extends Exception {

    public function __construct( $title, $message, $code = 0, Exception $previous = null ) {
        parent::__construct( $message, $code, $previous );

        echo '<html>';
        echo '<head>';
        echo '<title>Custom Exception: ' . $title . '</title>';
        echo '</head>';
        echo '<body>';
        echo '<h1>Custom Exception</h1>';
        echo '<hr />';
        echo '<p><strong>Error: </strong>' . $title . '</p>';
        echo '<p><strong>Message: </strong><em>' . $message . '</em></p>';
        echo '<hr />';
        echo '<p>This Exception was raised on: ' . date( 'Y-m-d' ) . ' at ' . date( 'H:i:s' ) . '.';
        echo '</body>';
        echo '</html>';
        http_response_code( $code );

        die();
    }

}

以die() 结束我的__construct 覆盖方法是否是一种好习惯，以防止输出任何父类“Exception”消息？

如您所见，它将 HTML 响应输出到浏览器中。我以前从未处理过自定义 PHP 异常，所以我想知道这是否会影响任何约定等？

【问题讨论】：

这在开发中是可以的，但在生产中不行。一旦你投入生产，不要向客户透露错误细节。只需显示一条通用的“发生错误”消息，记录所有详细信息并将其邮寄给您自己。

标签： php exception-handling die custom-exceptions

【解决方案1】：

DCoder 关于将错误发送给您或将其登录到文件中以便您稍后分析它有一个很好的观点，但是关于您的问题，死可能有点激烈，最好将应用程序的流程重定向到以通俗易懂的语言通知发生错误并且管理员将尝试解决该错误的页面。您可以通过多种方式改写它。

但是，重要的是，客户不应该被错误所困扰或气馁。如果你能解释错误的原因并告诉用户如何解决它，或者不再犯错误并重定向到最后一个好的步骤，那是最好的方法。如果你不能，那么你应该尝试解释并重定向到一个安全但有用的页面，比如主页或带有错误解释和资源的页面，比如搜索机器人、站点地图、导航工具或任何其他可能有帮助的东西。

我会说，永远不要杀死应用程序。

再见

【讨论】：