Question

我目前正在使用PHP。我正在为我正在构建的CMS构建一个错误系统（为了它的乐趣）。对于我系统中的致命错误（不是在PHP编译器中），我创建了一个FatalException类，它扩展了内置的Exception类。由于这些类型的错误无论如何都会停止系统，我在__construct中退出。

    class FatalException extends Exception{  
        public function __construct($message) {
            exit("<h1 style='color:red;' >FATAL ERROR: $message </h1>");
        }
    }

所以在我的代码中我会检查类似于数据库的连接，如果不能，那么我只会抛出一个FatalException（“无法连接到数据库：$ database_error_message”）。它不会在try / catch块中。

例如，当我运行代码并且无法连接到数据库时，我在屏幕上看到的只是一个大红色字母的句子。所以它运作得很好，但这是不好的做法/编码吗？

编辑：

实际上事实并非如此。我最初记录错误然后退出捕获区域，但后来我想，如果所有致命错误都要退出，那么只需放入构造函数。然后我注意到它实际上并没有到达它正在退出的捕获区域。因此将语句放在try / catch块中是一个有点问题。这导致了这个问题。

Answer 1

如果你在构造函数中无条件地去exit()，那么将它作为构造函数并不是很重要，更不用说使类成为Exception了。您可以更简单地（并且诚实地）拥有一个名为Fatal::Die($message)的静态函数。

例外的一点是，他们描述错误是什么（通过为不同的异常设置不同的类）并且可以被捕获 - 即使只是将它们记录到一个文件和保释程序。

如果您的网站的某个特定网页在没有数据库连接的情况下实际应对（只是错过了“最新新闻”或其他内容）会怎样？然后它可以catch( Database_Exception $e )并继续，而你的网站的其余部分直接进入最后的沟渠“哦没有出错”的消息。

大红色字母的消息也不是一个很好的错误处理机制，对于你以外的人会使用的任何东西 - 他们最终会在你不看的时候看到错误的技术细节，或者你没有知道出了什么问题，因为你隐藏了那个错误。

Answer 2

即使你将exit()包装到一个异常的成员函数中，你也没有在这里使用异常进行错误处理，只是exit() - 从不抛出异常，PHP停止之前发生了。

所以它运作得很好，但这是不好的做法/编码吗？

是的，这是不好的做法。如果您自己创建了一个函数，它也可以正常工作：

function error_exit($message) {
    exit("<h1 style='color:red;' >FATAL ERROR: $message </h1>");
}

而是考虑是否要使用Excpetions或想要exit()。

Answer 3

这是一个坏主意imho。需要捕获异常才能正常运行。但是，您可以创建一个类似 - ＆gt;错误（$ index）的方法;附在你制作的每一个物体上。从那里，您可以使用try / catch块将错误路由到特定的类，以正确处理错误。

class TestClass 
{
    public function error( $index )
    {
        try 
        {
        // Convert index to exception and throw it.
        }
        catch ( Exception $e )
        {
        // Handle the error
        }
    } 
}
$a = new TestClass();
$a->error( 1000 );

请注意，对于php抛出的异常，这将不，您需要单独捕获这些异常或与执行中心一起使用。

在try catch块中没有抛出异常是不好的编程？

3 个答案: