Gerry..

117

注意:首先,我意识到99%的PHP开发人员使用错误抑制操作符(我曾经是其中之一),所以我期待任何看到这个的PHP开发人员不同意.

在您看来,使用@运算符来抑制PHP中的错误/警告是否有效,而您可能正在处理错误？

简答:

不!

更正确的回答:

我不知道,因为我不知道一切,但到目前为止,我没有遇到过这是一个很好的解决方案的情况.

为什么它是坏的:

在我认为使用PHP大约7年的时候,我已经看到由错误抑制运算符引起的无休止的调试痛苦,并且从未遇到过无法避免的情况.

问题是,您正在抑制错误的代码段目前可能只会导致您看到的错误; 但是,当您更改受抑制的行所依赖的代码或其运行的环境时,该行有可能尝试从您尝试忽略的错误中输出完全不同的错误.那么如何追踪未输出的错误？欢迎调试地狱!

我花了很多年才意识到由于错误被压制,我每隔几个月浪费了多少时间.最经常(但不是唯一)这是在安装第三方脚本/应用程序/库之后,在开发人员环境中没有错误,但不是我的,因为php或服务器配置差异或缺少依赖性,这通常会立即输出错误提醒问题是什么,但不是当开发者添加魔法@时.

替代方案(取决于情况和期望的结果):

处理您知道的实际错误,以便如果一段代码将导致某个错误,那么它不会在该特定情况下运行.但我认为你得到了这个部分而你只是担心最终用户会看到错误,这就是我现在要解决的问题.

对于常规错误,您可以设置错误处理程序,以便在查看页面时以您希望的方式输出错误处理程序,但是对最终用户隐藏并记录这些错误处理程序,以便您知道用户触发的错误.

对于display_errors在php.ini中设置为关闭的致命错误(您的错误处理程序仍会被触发)并启用错误记录.如果你有一个开发服务器和一个实时服务器(我推荐),那么在开发服务器上不需要这一步,因此你仍然可以调试这些致命错误,而不必诉诸于查看错误日志文件.甚至还有一个技巧,使用shutdown函数向错误处理程序发送大量致命错误.

总结:

请避免它.可能有一个很好的理由,但我还没有看到一个,所以直到那天我认为(@)错误抑制操作符是邪恶的.

这绝对是正确的.抑制错误是一个根本性的错误.使用您的错误处理程序,或使用异常,不要隐藏错误. (21认同)

`-1`鹦鹉讽刺"是邪恶的"模因.避免使用内置语言功能而明确无视实际用例是货物崇拜编程的主要定义. - 特别是这种咆哮没有提到抑制错误实际上并没有消失.自定义错误处理程序仍然可以恢复它们(`set_error_handler("var_dump");`是scream扩展的惰性等价物).此外,这种过于宽泛的建议导致了普通的`isset()`通知抑制语法解决方法,这实际上可以阻碍调试(因为调试通知随后被无可挽回地抑制). (12认同)

@mario"明确无视实际用例"......嗯......也许你没有读过"邪恶"的全文."可能有一个很好的理由,但我还没有看到一个,所以直到那天我认为(@)错误抑制操作符是邪恶的".我说我还没有找到这样的背景.看起来你对Op提出的问题有了答案,也许你可以考虑提交一个有更多空间来讨论你的观点的答案. (4认同)

在检查索引值之前,您的代码不会检查索引是否存在.这将导致难以追踪问题,例如表单元素是重命名还是错误输入.不存在的索引意味着与表单元素不同的东西留空.此外,您不应该向最终用户显示错误.如果你只是在开发中遇到HTML/JSON问题,并认为留下它们没问题,这就是我们不同意的地方.典型执行路径上的通知通常表示无法处理您应该处理的条件. (3认同)