4

我在 php 中使用异常抛出函数对我的类中的参数进行了一些检查。我有执行基本检查（===等in_array）并在错误时引发异常的函数。所以我可以做assertNumeric($argument, "\$argument is not numeric.");而不是

if ( ! is_numeric($argument) ) {
    throw new Exception("\$argument is not numeric.");
}

节省一些打字

我正在阅读关于 assert() 的php手册页的评论

正如 Wikipedia 上所述 - “断言主要是一种开发工具，当程序向公众发布时，它们通常会被禁用。” 和“断言应该用于记录逻辑上不可能的情况并发现编程错误——如果发生‘不可能’，那么根本上的事情显然是错误的。这与错误处理不同：大多数错误情况都是可能的，尽管有些可能极不可能在实践中发生。使用断言作为通用错误处理机制通常是不明智的：断言不允许从错误中优雅恢复，并且断言失败通常会突然停止程序的执行。断言也不会显示用户友好的错误信息。”

这意味着“gk at proliberty dot com”给出的建议强制启用断言，即使它们已被手动禁用，这违背了仅将它们用作开发工具的最佳实践

那么，我是不是“做错了”？还有什么其他/更好的方法？

4

2 回答 2

1

就个人而言，我会第二个维基百科内容，而不是使用断言进行常规类型检查。

相反，我会使用 PHP 类型提示（目前正在处理 php 5.1 的对象和 php 5.2 的数组......不会帮助你处理基本数据类型，但总比没有好）；然后，您可以使用您暗示的功能，甚至更进一步，考虑 Ilia Alshanetsky 的一般类型提示补丁。见这里。

于 2010-05-11T23:43:02.243 回答
0

与常规断言一样，您应该能够通过方便的全局常量或变量或类构造函数方法关闭自定义断言。它们实际上不属于（活动的）生产代码，或者默认情况下在任何类型的库中都是活动的。对于您使用它们执行的操作，即使您可以关闭它们，这似乎也是在浪费 CPU 周期。

在较低级别的语言中，断言对于捕捉非常奇怪的情况非常有用，例如过度热心的架构特定编译器优化所产生的错误。例如，您知道在任何理智的宇宙中，断言的条件都会为真。然后你的编译器撕裂了时空结构，一切都发生了变化。因此，如果您使用 PHC 或 Roadsend 之类的工具来编译您的应用程序，它们可能会很有用。

我还看到过“过于安全”的代码（主要是 C 语言），其中每个函数的入口都受到断言的保护。我真的怀疑这样做是否明智。

简而言之，您希望您的代码优雅地失败或根本不失败，而不仅仅是停止，尤其是在它取决于用户输入的情况下。断言只报告评估为假的条件，它们不处理错误。

于 2010-05-12T00:06:20.243 回答