1

我经常与我的一位同事讨论在面向对象的 PHP 项目中最合适的“执行”错误处理方式。

他认为我们应该继续使用Exceptions(遗留代码)。在他的方法论中,您将有如下方法:

private function doSomething() { if (condition) { throw new CustomException("error message"); } }

然后,您将在 try catch 块中调用它并将异常错误添加到错误数组中(然后您可以根据自己的选择输出)。

在上面的示例中,条件是一个布尔比较,对于它来说接收真或假响应是完全合理的。

像这样的帖子:PHP类中的错误处理似乎同意这个立场..

我的观点是,因为真或假都是完全合理的反应,所以这是对异常的不恰当使用。错误不是异常的,而是完全正常的。

因此,我已经创建了一个自定义错误类,您可以在方法顶部对其进行实例化。然后,您将方法中的任何错误添加到此实例的错误数组属性中。然后,您从您的方法返回此实例,并可以调用passesConditions()该类的方法,该方法返回一个布尔值,具体取决于是否有任何错误。

这种方法始终是可扩展的,因为您可以以一致的方式记录所有失败(我很感激您可以使用 Exceptions 做类似的事情 :))

那么我们中的任何一个都比另一个更正确,如果是,为什么?

非常感谢

4

1 回答 1

0

我开始认为基于异常的开发很糟糕,尽管我还不能完全确定。但我不同意你关于“假和真都是有效结果”的说法。当然,对于普通布尔值而言,这是正确的,但在您正在测试的代码的上下文中。例如,如果你想请求一个文件,该文件必须存在,所以 FileExists 应该返回 true。它可能返回 false,这本身是有效的,但在此文件加载器脚本的上下文中无效。在另一个示例中,您可以执行 HTTP 请求并将其结果状态代码作为整数获取。虽然 404、500 甚至 -1 都是非常好的整数,但它们表示异常状态,假设您希望 url 返回正确的 200 OK(或者可能是 304 Not modified)。

因此,您将错误记录到您的班级这一事实表明,即使您同意这是一个错误的值。是否通过引发异常来解决这个问题是完全不同的讨论。

就个人而言,我不太喜欢您的解决方案。我认为它会使代码混乱,因为您总是必须处理生成的对象(而异常可以在更高级别上捕获)。此外,如果您还想从函数返回一个实际值,那么该对象将成为障碍,除非您使用包含实际结果的额外属性对其进行扩展,但我认为您真的会迷失在自己的代码中,真的很快。

于 2013-11-12T22:17:27.110 回答