php - 我什么时候编写自己的异常类？

Question

自从我走进OOP的浑水，并且在有必要编写自己的异常类扩展时编写了大约两个分布式库之后，我一直在想。

到目前为止，我仅使用内置的异常类，它似乎对我很有用。是否有必要，如果可以，我可以编写一个异常子类。

Answer 1

当需要区分不同类型的错误时，应使用自己的Exception类型扩展Exception类。抛出Exception只是意味着出了点问题。您不知道出了什么问题。你应该放弃一切吗？这是预期的错误吗？相反，抛出UserIsNotAllowedToDoThisException意味着更具体。重要性在于区分哪些代码可以处理哪种类型的错误:

try {
    new Foo($bar);
} catch (UserIsNotAllowedToDoThisException $e) {
    echo "Sorry, you're not allowed to do this.";
}

此代码处理不允许出现某些情况的简单情况。如果 Foo会引发其他异常，例如 TheDatabaseJustCrashedAndIsBurningException，则您不想在这里了解此情况，而是需要一些全局错误处理程序来处理它。通过区分出问题所在，它可以使您适当地处理问题。

好的，这里有一个更完整的例子:

首先，如果使用正确的OOP，则需要异常才能使对象构造失败。在无法使对象构造失败的情况下，您将忽略OOP的大部分内容:类型安全性，因此也保证了数据完整性。参见例如:

class User {

    private $name = null;
    private $db = null;

    public function __construct($name, PDO $db) {
        if (strlen($name) < 3) {
            throw new InvalidArgumentException('Username too short');
        }
        $this->name = $name;
        $this->db = $db;
        $this->db->save($this->name);  // very fictional DB call, mind you
    }

}

在此示例中，我们看到了很多东西:

我的User对象必须具有名称。未能将$name参数传递给构造函数将使PHP在整个程序中失败。

用户名至少应包含3个字符。如果不是，则无法构造该对象(因为抛出异常)。

我的User对象必须具有有效且有效的数据库连接。

如果不传递$db参数，将使PHP在整个程序中失败。

如果未传递有效的PDO实例，则会使PHP导致整个程序失败。

我不能只传递任何内容作为第二个参数，它必须是有效的PDO对象。

这意味着如果PDO实例的构建成功，则我具有有效的数据库连接。此后，我无需担心或检查数据库连接的有效性。这就是我构造User对象的相同原因；如果构建成功，则我有一个有效的用户(有效的意思是他的名字至少3个字符长)。我不需要再次检查。曾经。我只需要为User对象键入提示，PHP就会处理其余的工作。

因此，您会看到OOP + Exceptions为您提供的功能。如果您具有某个类型的对象的实例，则可以100％保证其数据有效。与在任何中途复杂的应用程序中传递数据数组相比，这是一个巨大的进步。

现在，上面的 __construct可能由于两个问题而失败:用户名太短，或者数据库由于某种原因无法正常工作。 PDO对象是有效的，因此在构造对象时连接正在工作，但与此同时它可能已断开。在这种情况下，对 $db->save的调用将抛出其自己的 PDOException或其子类型。

try {
    $user = new User($_POST['username'], $db);
} catch (InvalidArgumentException $e) {
    echo $e->getMessage();
}

因此，我将使用上面的代码来构造一个 User对象。我不会事先检查用户名是否至少3个字符长，因为这会违反DRY原则。相反，我只是让构造函数担心它。如果使用 InvalidArgumentException进行构建失败，我知道用户名不正确，因此我将通知用户。

如果数据库关闭了怎么办？然后，我将无法继续在当前应用中执行任何操作。在那种情况下，我想完全停止我的应用程序，显示一个HTTP 500 Internal Server Error页面。这是一种实现方法:

try {
    $user = new User($_POST['username'], $db);
} catch (InvalidArgumentException $e) {
    echo $e->getMessage();
} catch (PDOException $e) {
    abortEverythingAndShowError500();
}

但这是 不好的方式。数据库可能会随时在应用程序中的任何地方发生故障。我不想在将数据库连接传递给任何对象的每一步都执行此检查。我要做的是让异常冒出来。实际上，它已经泡沫化了。该异常不是由 new User引发的，而是在对 $db->save的嵌套函数调用中引发的。异常至少已经传播了两层。因此，我只是让它走得更远，因为我已经设置了全局错误处理程序来处理 PDOExceptions(它正在记录错误并显示了一个不错的错误页面)。我不想担心这里的特定错误。因此，它来了:

使用不同类型的异常可以使我在代码中的某些点忽略某些类型的错误，并让我的代码的其他部分来处理它们。 如果我有某种类型的对象，则不必质疑，检查或担心其有效性。如果无效，那么我一开始就不会有它的实例。并且，如果它曾经一直无效(例如突然失败的数据库连接)，则 对象可以通过自身发出信号发生错误。我需要做的只是在正确的位置 catch Exception(可能很高)，我不需要检查程序中的每个点是否成功。结果是更少，更健壮，结构更好的代码。在这个非常简单的示例中，我仅使用通用的 InvalidArgumentException。在带有一些接受许多参数的对象的更复杂的代码中，您可能希望区分不同类型的无效参数。因此，您将创建自己的Exception子类。

尝试通过仅使用一种异常来复制它。尝试仅使用函数调用和 return false复制此内容。每次需要进行检查时，您都需要更多的代码来执行此操作。编写自定义异常和自定义对象需要更多的代码和明显的前期复杂性，但是从长远来看，它可以节省以后的大量代码，并使事情变得更加简单。因为任何不应该的内容(例如用户名太短的用户)都可以确保导致某种错误。您无需每次都检查。相反，您只需要担心要在哪一层包含错误，而不用担心是否会找到它。

而且，“编写您自己的异常”实际上是不费吹灰之力的:

class UserStoppedLovingUsException extends Exception { }

在这里，您已经创建了自己的Exception子类。现在，您可以在代码中的适当位置对其进行 throw和 catch编码。您不需要做更多的事情。实际上，您现在已经正式声明了应用程序中可能出错的事物的类型。这是否击败了许多非正式文档以及 if， else和 return false？