Question

我们有一个标准在使用，我们在主类中创建异常以返回错误等...问题是，所有标准的嗅探都不喜欢这样。我们正在为此写自己的嗅觉，但我想我会问为什么这不可取？

例如，我们有：

<?php
class FOO_EXCEPTION extends Exception   {   }
class FOO_EXCEPTION_BAR extends FOO_EXCEPTION   {   }
class FOO_EXCEPTION_POLE extends FOO_EXCEPTION  {   }

class FOO
{
    public function MethodDoingSomething()
    {
        if('some condition happens')    {
            throw new FOO_EXCEPTION_BAR();
        }

        if('some other condition')  {
            throw new FOO_EXCEPTION_POLE();
        }
        ...
    }
}
?>

这允许我们的代码返回不同的异常以指示调用者发生了什么，但是如果没有专用的try / catch，则仍然可以捕获基本的异常。

这在使用数据库或其他外部对象时非常方便，因为错误的性质可能会返回到调用堆栈上方的组件来处理错误。

例如，如果要删除文件，并且该文件不存在，则代码可能会抛出异常，但如果调用者不关心该文件不存在，则可以选择忽略该文件，因为它无论如何都试图删除它。但是，另一个调用者可能会因缺少一个在删除时存在的文件而出错。

Answer 1

在我看来，您在问题中描述的编码标准是完全合理的。我认为，为了您的项目的目的，最好调整“每个文件的标准多个类”嗅探，以便它与您的代码在这个特殊（特殊）情况下使用而不是浪费你的时间调整你的代码库，以符合这个特定嗅探的“法律条文”。

我同意断言一般更好以避免将多个类定义放在单个文件中。但是我已经读过（到目前为止）将每个 Exception派生类转移到它自己的单独文件中的每个参数都让我感到沮丧，因为它使代码变得不那么容易“改进”代码。作为一个人，我不会因为包含单行的文件而使我的代码混乱而无法获得可维护性。

确实，编写自动加载器更容易，例如，如果每个类都存在于自己的文件中。如果您从某种元语言生成/编译PHP代码，那么在您的目录结构中添加额外的级别则无需任何费用。但我拒绝这样的结论：这种组织代码的方式实际上以任何有用的方式改进了它。

修改为了记录，我可以看到将Exception派生类的定义移动到它自己的文件中是一个好主意如果它实际上包含一些“可测试的”逻辑。在这种情况下，您可能需要在为使用类的逻辑编写自动化测试时模拟/存根该类，这将要求您能够将类定义与使用它的逻辑分开加载。但是这个不原始问题中描述的情况，其中Exception派生类都是“空”。

PHP_CodeSniffer每个文件的许多类嗅探

1 个答案: