3 回答
TA贡献1829条经验 获得超7个赞
TA贡献1770条经验 获得超3个赞
首先,我意识到99%的PHP开发人员使用错误抑制操作符(我曾经是其中之一),所以我希望任何PHP开发人员都会对此持不同意见。
在您看来,使用@运算符来抑制PHP中的错误/警告是否有效,而您可能正在处理该错误?
简短答覆:
不!
更长更正确的答案:
我不知道,因为我不知道一切,但到目前为止,我还没有遇到这样的情况,这是一个很好的解决方案。
为什么是坏的:
在我认为使用PHP大约7年的时间里,我已经看到了错误抑制操作符所造成的无休止的调试痛苦,而且从来没有遇到过不可避免的情况。
问题是,您正在消除错误的代码段当前可能只会导致所看到的错误;但是,当您更改被抑制的行所依赖的代码或它运行的环境时,很有可能该行将尝试输出与您试图忽略的错误完全不同的错误。那么,如何跟踪没有输出的错误呢?欢迎来到调试地狱!
我花了很多年才意识到,我每隔几个月就会因为被压制的错误而浪费多少时间。大多数情况下(但不只是如此),这是在安装第三方脚本/应用程序/库之后,在开发人员环境中没有错误,但不是我的,因为php或服务器配置不同,或者缺少依赖,通常会立即输出错误,提醒问题所在,而不是开发人员添加了魔术@。
替代品(视情况和预期结果而定):
处理您所知道的实际错误,这样如果一段代码将导致某个错误,那么它就不会在特定情况下运行。但我想你知道这个部分,你只是担心最终用户会看到错误,这就是我现在要解决的问题。
对于常规错误,您可以设置一个错误处理程序,以便在您查看页面时以您希望的方式输出这些错误,但对最终用户隐藏这些错误并将其记录下来,这样您就可以知道您的用户触发了哪些错误。
对于致命错误集display_errors
在php.ini中关闭(您的错误处理程序仍然被触发)并启用错误日志记录。如果您有一个开发服务器和一个活动服务器(我建议这样做),那么这个步骤在您的开发服务器上是不必要的,所以您仍然可以调试这些致命错误,而不必求助于查看错误日志文件。甚至有一个使用关机函数的技巧向错误处理程序发送大量致命错误。
总括而言:
请避开它。这可能有一个很好的理由,但我还没有看到,所以直到那天,我才认为(@)错误抑制操作符是邪恶的。
TA贡献1852条经验 获得超7个赞
是的,压制是有道理的。
例如,fopen()
命令返回FALSE
如果无法打开文件。很好,但是也生成PHP警告消息。通常你不想要警告-你会检查FALSE
你自己。
- 3 回答
- 0 关注
- 635 浏览
添加回答
举报