如何命名异常（PHP）？答案

【问题标题】：How to name exceptions (PHP)?如何命名异常（PHP）？
【发布时间】：2012-07-13 02:25:37
【问题描述】：

我正在从事一个非常大的项目，并且在 stackoverflow 和其他网站上阅读了很多关于异常的信息。结果是，有100％的正确或错误。有些会为无效的用户输入抛出异常，有些则不会。有些仅针对运行时错误抛出异常，有些则不会...

我个人喜欢即使是无效的用户输入也抛出异常的方式。

现在我的问题是，例如，我有一个用户可以评论另一个用户的陈述（例如他/她最喜欢的音乐等）。每个用户只能评论一次。现在，为评论创建数据库条目的函数检查用户是否已经对该语句发表了评论。如果是，则抛出异常。通常我会说我将这个异常命名为：ExceptionStatementAlreadyCommented 但是我在这个项目中还有许多其他功能，如果我总是创建这样的特定异常，我最终会得到大约 100 - 200 个异常。

这会影响性能吗？我通过 __autoload 函数自动加载需要的类，所以实际的异常只在需要时才加载。

这样命名异常是个好方法吗？过去，我很难将一个异常用于不同的错误，因为当我捕获异常时，有时会捕获我不想捕获的异常。

非常感谢您的帮助！

最好的问候，

弗雷迪

【问题讨论】：

看起来像是过度设计，为什么不使用您自己的消息发送一个普通的Exception？

标签： php performance exception

【解决方案1】：

最好有一个异常树，从最一般的延伸到最具体的，例如，你的StatementAlreadyCommentedException（应该是这样命名的，最后是异常部分）应该继承自@987654322 @，或者可能是 AlreadyExistsException 异常，这些应该继承自更一般的东西，例如 Exception。

这样，您可以捕获比您正在搜索的异常更具体的所有异常（如果您需要它）。（你可以捕获Exception，它会捕获所有可能的异常，你可以捕获AlreadyExistsException，它会捕获任何扩展它的异常。

【讨论】：

【解决方案2】：

我的感觉是你已经过度使用异常了。正如名称所引用的那样，仅应在特殊情况下引发预期。

不应使用异常来控制应用程序的流程。用户输入错误数据或未输入正确的用户名和密码将被视为您的应用程序正常流程的一部分，而不是异常情况。

您应该只在可能导致整个或部分应用程序无法使用的特殊情况下抛出异常，例如，无法连接到数据库。

这样，您最终不会在系统中遇到太多需要捕获甚至重新抛出的异常。

最好有不同的异常，例如，我使用RedBean ORM 与我的数据库通信，它使用这些异常：

RedBean_Exception_Security（发生安全异常时）。
RedBean_Exception_SQL（出现错误的 sql 语法或其他问题时）。

对异常过于具体会导致很多混乱。例如，如果我对missing sql column、bad syntax、missing value 等有一个例外，它会变得非常难以管理。但是，如果我有一个SQL_Exception，并且对上述所有情况都使用该异常，那么管理起来会更加整洁和简单。

至于性能，必须加载大量类（我假设它们在外部文件中）可能会对应用程序造成负担。这可以通过使用APC 在内存中缓存解释的 PHP 代码来部分缓解。但是，如果没有任何分析，这很难说。

【讨论】：

好吧，我正在苦苦挣扎的一件事是，为什么甚至需要创建不同的异常而不是仅仅抛出一个简单的Exception。我知道，对异常进行分类是有意义的，但是如果所有未捕获的异常都可以终止进程，那么你捕获它们的名称并不重要，因为每个脚本停止程序都必须稍后用exception 捕获..
对它们进行分类的好处是，如果您想记录它们以供以后分析，它会使事情变得更容易。例如，您可以使用fluentd 之类的东西在终止之前拦截并登录全局异常处理程序。如果对异常进行分类，则可以很容易地使用 fluentd 存储它并使用 kabana 之类的东西对其进行分析。然后你可以问像what are the most common database connection failures and why?，When do we often have problems sending email using our transactional email provider's api?这样的问题
对不起，我是说kibana日志分析软件而不是kabana香肠。不幸的是，我的评论不再可编辑，所以我希望这条评论会有所帮助。
是的，它有帮助。我明白你说的。谢谢

【解决方案3】：

为每种可能的错误类型创建单独的异常类是没有意义的。这个想法是异常类名称应该粗略地描述错误，并且每个类都应该有适当的变量来设置，以便与异常消息一起描述确切的错误。

虽然当前的方法不会影响您的性能（至少异常类的数量不会），但它可能会影响您的可维护性，因为听起来有相当多的心理开销实际上并没有产生任何有形的好处。

如果您创建一个经过深思熟虑的异常层次结构，而不是生成直接扩展\Exception 的 200 个异常类，事情也会好得多。

例如，对所有类似情况使用类似RecordAlreadyExistsException 的异常，而不是对每种情况使用ThisTypeOfRecordAlreadyExistsException。

【讨论】：