我们使用了一个标准，在主类中创建异常以返回错误等。问题是，所有的标准嗅探器都不喜欢这样。当时我们正在为此写自己的嗤之以鼻的文章，但我想我会问为什么这不可取？
例如，我们有：
<?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，则基本异常可能仍然被捕获。
这在处理数据库或其他外部对象时很有用，因为错误的性质可能会返回到调用堆栈中更高级别的组件来处理错误。
例如，如果您正在删除一个文件，而该文件不存在，则代码可能会引发异常，但调用方可以选择忽略此异常，如果它不担心文件不存在的话，因为它无论如何都在尝试删除它。然而，另一个调用程序可能会出错，因为在删除文件时，该文件被认为是存在的。
在我看来，您在问题中描述的编码标准是完全合理的。我认为，就您的项目而言，最好调整"每个文件标准多个类"的嗅探，以便在这种特定(特殊)情况下与您的代码协同工作，而不是浪费时间调整代码库以符合这种特定嗅探的"法律条文"。
我同意这样一种说法，即通常最好避免将多个类定义放在一个文件中。但是，(到目前为止)我读到的关于将每个异常派生类移动到其自己的单独文件中的每一个论点，都让我觉得是在劝告通过降低代码的可读性来"改进"代码。作为一个人，我不会因为将代码与每一行都包含一行的文件混杂在一起而获得可维护性的好处。
的确，编写自动加载器更容易，例如，如果每个类都位于自己的文件中。如果你用某种元语言生成/编译PHP代码，那么在目录结构中添加额外的级别就不需要花费任何代价。但我拒绝接受这样的结论，即这种组织代码的方式实际上以任何对人类有用的方式改进了它。
编辑：对于记录，我可以看到，如果实际上包含一些"可测试"逻辑，那么将Exception派生类的定义移动到它自己的文件中是个好主意。在这种情况下，当为使用类的逻辑编写自动测试时，您可能需要模拟/存根类，这将要求您能够将类定义与使用它的逻辑分开加载。但这不是原始问题中描述的情况，其中Exception派生的类都是"空的"。