抑制设置 ERROR_REPORTING 之外的错误(也许是 display_errors?)
假设我基本上继承了一个在生产中存在很多错误的实时网站,我基本上正在对这个整个网站进行重新编码,这可能需要一个月或所以。
在某些情况下,该站点依赖于不再存在的外部 xml 文件提要,但代码未正确设置以提供清晰的错误消息(存在各种类似的情况)- 客户端要求在至少,即使 xml 文件中的内容未发布,这些错误消息也会消失,因此我们不会看到 php 错误和页面上的空白区域(因此页面的其余部分看起来“很好”)。
有一次,我听说有人使用 set_error_handler 来取消某些不是极端的情况,我想到了将其设置为将错误消息存储在文件/日志中或通过电子邮件发送给他们(并且尽量不要有重复的错误消息)基本上这样最终用户就不必看到那些丑陋的东西。
我正在寻找真正做过这件事的人的建议,所以提前致谢。
Let's say I'm basically inheriting a live site that has a lot of errors in production, I'm basically doing a recode of this entire site which might take a month or so.
There are some cases in which this site was reliant upon external xml file feeds which are no longer there, but the code wasn't properly setup to supply a nice clean error message ( there are various similar circumstances ) - the client is requesting that at least these error messages go away even if for example the content from the xml file isn't published so we wouldn't be seeing php errors and a blank region on the page ( so the rest of the page can look "fine" ).
At one point I have heard of someone using set_error_handler to nullify some cases where it isn't extreme and I had the idea of setting it up to store error messages in a file/log or email them ( and try to not have duplicate error messages ) basically so end users don't have to see those ugly things.
I'm looking for tips from anyone who's actually done this, so thanks in advance.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
在开发时,最好使用
“所以你可以立即看到错误”:它有助于纠正它们。
在生产服务器上时,您不希望显示错误,因此:
error_reporting
可以保持激活状态:如果display_errors
关闭,则无论如何都不会显示错误 - 但是您仍然可以将它们记录到文件中。顺便说一句,这些当然可以在 php.ini 文件中设置:
error_reporting
显示错误
在生产计算机上,您可能需要使用
log_errors
和error_log< /code>
,因此错误会记录到文件中(这意味着您将能够知道发生了什么错误 - 有时可能很有用); 当然,不要忘记时常检查该文件;-)。
作为旁注,如果您只有几个函数/方法,并且不想显示错误,则可以设想使用 @operator 只是掩盖可能触发的错误......
但我强烈建议不要这样做(除非在非常特殊的情况下):它使调试变得更加困难:触发的错误永远不会显示,即使在您的开发机器上也不会显示!
在我看来,最好在生产机器上禁用
display_errors
; 这也意味着根本不会显示任何错误,这对用户来说更好!When in development, it is good to use
So you can see errors immediatly : it helps correcting them.
When on the production server, you don't want error displayed, so :
error_reporting
can remain activated : ifdisplay_errors
is Off, errors won't be displayed anyway -- but you can still have them logged to a file.BTW, those can be set in the php.ini file, of course :
error_reporting
display_errors
On the production machine, you might want to use
log_errors
anderror_log
, so errors are logged to a file (which means you will be able to know what errors occured -- can be useful, sometimes) ; of course, don't forget to check that file from time to time ;-).As a sidenote, if you just have a couple functions/methods you don't want to display errors, you could envisage using the @ operator to just mask the errors those might trigger...
... But I strongly advise against it (except in very specific cases) : it make debugging lots harder : errors triggered there are never displayed, not even on your development machine !
In my opinion, it is way better to just disable
display_errors
on the production machine ; it also means no error will be displayed at all, which is better for users!在生产服务器上,您应该具有以下 ini 设置:
通过关闭
display_errors
,您的用户将永远不会看到其他错误消息,但您将能够看到错误消息通过查看日志文件。重新编码完成后,日志文件中不应再有错误(因为您已修复所有错误)。
编辑:一些开发人员将
error_reporting
设置为E_ALL ^ E_NOTICE
作为隐藏错误的一种方式。 这是不好的做法,因为它隐藏了有关可能的编程错误的消息。 仅当有太多来自旧代码的通知而您无法全部修复它们时,才应该使用E_ALL ^ E_NOTICE
。On your production server, you should have the following ini settings:
By turning off
display_errors
, your users will never see another error message, but you will be able to see error messages by looking in the log file.When the re-code is finished, there should be no more errors going into the log file (because you've fixed them all).
Edit: Some developers set
error_reporting
toE_ALL ^ E_NOTICE
as a way of hiding errors. This is bad practice because it hides messages about possible programming errors. You should only useE_ALL ^ E_NOTICE
when there are so many Notices coming from legacy code that you are unable to fix them all.