在 php 中使用断言进行类型检查？
我使用异常抛出函数对 php 中的类中的参数进行了一些检查。我有一些函数可以进行基本检查（ === 、 in_array 等）并在 false 时抛出异常。所以我可以做 assertNumeric($argument, "\$argument is not numeric."); 而不是
if ( ! is_numeric($argument) ) {
throw new Exception("\$argument is not numeric.");
}
内容
保存我在 assert() 上的 php 手册页
正如维基百科上所述 - “断言 主要是一个开发工具，它们 当程序运行时通常会被禁用 向公众发布。”和 “断言应该用于记录 逻辑上不可能的情况和 发现编程错误——如果 “不可能”发生了，然后发生了一些事情 基本面显然是错误的。这是 与错误处理不同：大多数 可能出现错误情况， 尽管有些可能非常 实际中不太可能发生。使用 断言作为通用错误 处理机制通常是不明智的： 断言不允许优雅 从错误中恢复，并断言 失败通常会导致程序停止 突然执行。断言也可以 不显示用户友好的错误 消息。”
这意味着给出的建议 “gk at proliberty dot com”强制 断言被启用，即使当 它们已被手动禁用，继续 反对仅使用的最佳实践 将它们作为开发工具
那么，我“做错了吗”？还有哪些其他/更好的方法可以做到这一点？
I do some checking of arguments in my classes in php using exception-throwing functions. I have functions that do a basic check ( ===, in_array etc ) and throw an exception on false. So I can do assertNumeric($argument, "\$argument is not numeric."); instead of
if ( ! is_numeric($argument) ) {
throw new Exception("\$argument is not numeric.");
}
Saves some typing
I was reading in the comments of the php manual page on assert() that
As noted on Wikipedia - "assertions
are primarily a development tool, they
are often disabled when a program is
released to the public." and
"Assertions should be used to document
logically impossible situations and
discover programming errors— if the
'impossible' occurs, then something
fundamental is clearly wrong. This is
distinct from error handling: most
error conditions are possible,
although some may be extremely
unlikely to occur in practice. Using
assertions as a general-purpose error
handling mechanism is usually unwise:
assertions do not allow for graceful
recovery from errors, and an assertion
failure will often halt the program's
execution abruptly. Assertions also do
not display a user-friendly error
message."This means that the advice given by
"gk at proliberty dot com" to force
assertions to be enabled, even when
they have been disabled manually, goes
against best practices of only using
them as a development tool
So, am I 'doing it wrong'? What other/better ways of doing this are there?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
就我个人而言，我会支持维基百科内容，而不是使用断言进行常规类型检查。
相反，我会使用 PHP Type-Hinting（目前正在处理 php 5.1 的对象和 php 5.2 的数组......不会帮助您处理基本数据类型，但它仍然比没有好）；然后，您可以使用您暗示的函数，甚至可以更进一步，考虑 Ilia Alshanetsky 的通用类型提示补丁。 请参见此处。
Personally I'd second Wikipedia content and not use assertions for regular type checking.
Instead, I'd use PHP Type-Hinting (currently working on objects as php 5.1 and arrays as of php 5.2 ...won't help you with basic data types, but it's still better than nothing); you can then use the functions you were hinting at or even go a little further and consider Ilia Alshanetsky's patch for general type hinting. See here.
与常规断言一样，您应该能够通过方便的全局常量或变量或类构造函数方法关闭自定义断言。它们确实不属于（活跃的）生产代码，或者默认情况下在任何类型的库中都是活跃的。对于您使用它们执行的操作，即使您可以关闭它们，这似乎也是浪费 CPU 周期。
在较低级别的语言中，断言对于捕获非常奇怪的情况非常有用，例如由于过度热心的体系结构特定编译器优化而产生的错误。例如，您知道在任何理智的宇宙中，所断言的条件都将成立。然后你的编译器会撕裂时空结构，一切都会改变。因此，如果您使用 PHC 或 Roadsend 之类的东西来编译您的应用程序，它们也许会很有用。
我还看到过“过于安全”的代码（主要是 C 语言），其中每个函数的入口都受到断言的保护。我真的怀疑这样做是否明智。
简而言之，您希望您的代码正常失败或根本不失败，而不仅仅是停止，尤其是在它依赖于用户输入的情况下。断言仅报告评估结果为 false 的条件，它们不处理错误。
As with regular assertions, you should be able to turn your custom assertions off via a convenient global constant or variable or class constructor method. They really do not belong (active) in production code, or active by default in any kind of library. For what you are using them to do, it seems like a waste of CPU cycles even if you could turn them off.
In lower level languages, assertions are very useful to catch very strange situations such as bugs created by over-zealous architecture specific compiler optimizations. For instance, you know that in any sane universe, the asserted condition is going to be true. Then your compiler rips apart the fabric of space time and everything changes. So, perhaps they would be useful if you were using something like PHC or Roadsend to compile your app.
I have also seen 'overly secure' code (mostly in C) where the entrance to every single function is guarded by assertions. I really question the wisdom of doing that.
In short, you want your code to fail gracefully or not at all, not just halt, especially if it depends on user input. Assertions only report conditions that evaluate to false, they don't handle errors.