2

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

例如，我们有：

<?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 不可用，则可能仍然会捕获基本的异常。

这在使用数据库或其他外部对象时会派上用场，因为错误的性质可能会返回到调用堆栈更高的组件以处理错误。

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

4

1 回答 1

2

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

我同意这样的断言，即通常最好避免将多个类定义放在一个文件中。但是（到目前为止）我读过的关于将每个异常派生类移动到其自己的单独文件中的每一个论点都让我印象深刻，因为它是通过降低可读性来“改进”代码的。作为一个人类，我没有从将我的代码与包含单行的文件混在一起中获得可维护性的好处。

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

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

于 2013-01-07T04:47:40.587 回答