我经常与我的一位同事讨论在面向对象的PHP项目中“做”错误处理的最合适方式。
他认为我们应该继续使用例外（遗留代码）。 在他的方法论中，您将得到如下方法：
private function doSomething() {
if (condition) {
throw new CustomException("error message");
}
}
然后，您将在try catch块中调用它，并将异常错误添加到错误数组中（然后可以根据您的选择输出）。
在上面的例子中，条件是一个布尔比较，接收真或假响应是完全合理的。
像这样的帖子：Error Handling in a PHP Class似乎同意这个立场..
我认为，因为真或假都是完全合理的回答，所以这是对例外的不当使用。虚假不是特殊的，而是完全正常的。
因此我已经创建了一个自定义错误类，您可以在方法的顶部实例化它。然后，您的方法中的任何错误都会添加到此实例的errors数组属性中。然后，您可以从方法返回此实例，并可以调用类的passesConditions()方法，该方法返回一个布尔值依赖于是否存在任何错误。
这种方法总是可扩展的，因为你可以以一致的方式记录所有的失败（我感谢你可以做与Exceptions类似的事情:)）
所以我们中的任何一方都比另一方更正确，如果是这样，为什么呢？
非常感谢
答案 0 :(得分：0)
我开始认为基于异常的开发很糟糕，尽管我还不完全确定。 但我不同意你的说法，即“虚假和真实都是有效的结果”。当然，对于普通布尔值，这是正确的，但是在您正在测试的代码的上下文中。例如，如果要请求文件，则该文件必须存在，因此FileExists应返回true。它可能返回false，这本身是有效的，但不在此文件加载器脚本的上下文中。 在另一个示例中，您可以执行HTTP请求并将其结果状态代码作为整数获取。虽然404,500和甚至-1是非常好的整数，但它们表示异常状态，假设您希望url返回正确的200 OK（或者可能是304 Not modified）。
因此，您正在向您的班级记录错误，这表明即使您同意这是错误的价值。是否通过提出异常来解决这个问题是一个完全不同的讨论。
就个人而言，我不太喜欢你的解决方案。我认为它使代码混乱，因为你总是必须处理结果对象（而异常可以在更高层次上捕获）。此外，如果你想从函数中返回一个实际值，那么该对象将会妨碍，除非你用一个包含实际结果的额外属性来扩展它，但是我认为你会在你自己的代码中迷失，很快。