我有一些可能定义或未定义的变量（$isLoggedIn布尔值），我正在尝试清除错误消息。我想知道是否有任何理由我不应该使用错误抑制器操作符：
if (@$isLoggedIn)
或者，如果我应该首先检查变量的存在：
if (isset($isLoggedIn)and$isLoggedIn)
在生产环境中，这两种方法都有任何缺点/好处吗？这两个语句的功能是相同的，并且没有因未定义此var而导致的问题。但它不应该记录为错误。
答案 0 :(得分：3)
如果您使用变量，它应该存在。您的代码不应该禁止错误，您应该修复它们或处理它们。
答案 1 :(得分：3)
根据我的经验，你不应该在个人层面上压制错误。在生产环境中，将错误报告设置为0并将错误显示为关闭。当你在6个月内回来修复错误时，让自己陷入困境中，忘记它就在那里，并且无法解决为什么没有错误出现但有些东西明显被打破。
在您的特定情况下，只需将$ isLoggedIn设置为false，然后在当前实例化它的位置覆盖该值（我假设代码结构在这里）。
答案 2 :(得分：1)
在您的代码中使用一堆错误抑制器会使维护更加困难，尤其是对于除您自己之外的其他人。下一个人现在必须学习以他习惯的不同方式查看代码。抑制只是一个黑客，并将导致其他人试图弄清楚为什么有一个黑客可能会减慢任何调试工作。
执行if（@ $ var）会产生与if（！empty（$ var））相同的结果，所以只需使用它，因为它是检查它的语义更正确的方法。
答案 3 :(得分：1)
http://php.net/manual/en/language.operators.errorcontrol.php
您的变量应始终存在，至少将其初始化为false，并在登录后将其设置为true。在抑制方面，我建议使用第二种方法。
警告
目前，“@”错误控制操作符前缀甚至会禁用错误报告，以解决将终止脚本执行的严重错误。除此之外，这意味着如果你使用“@”来抑制来自某个函数的错误，并且它不可用或者输入错误，那么脚本就会在那里死亡而没有任何关于原因的指示。
答案 4 :(得分：1)
您永远不应该允许PHP在公共网站上向浏览器写入错误消息。您应该始终记录它们，并且尽可能在代码中处理它们 - 即使它是通过set_error_handler（）。
现在我们已经解决了这个问题....
这是一个警告，而不是错误。
是的警告信息有时可能是PITA。但有些人喜欢严格的变量检查。使用抑制运算符提供了一种比抑制所有E_STRICT消息更有针对性的方法，所以即使我喜欢PHP支持允许使用变量withot声明，这就是我所做的（并且使用try {} catch（）也适用）
因此，在适当的时候使用任何一种方法 - 但是当它们没有被抑制时，请记录这些警告 - 这些是你需要修复的东西 - 即使修复只是添加抑制。
答案 5 :(得分：0)
最逻辑的方法是始终声明这些变量 - 尤其是像$isLoggedIn这样的重要变量 - 并检查它是否为真：
if ($isLoggedIn)
或仅设置它，如果它是真的：
if (isset($isLoggedIn)
在我看来，第一个选择更好，混合两者都不是一个好的解决方案！
答案 6 :(得分：0)
如果我不确定是否设置了变量，但我想知道它是否为真，那么我写道：
if(!empty($var)){}
但是，您应该构建代码，以便始终确定您的变量。 你应该避免使用全局变量。
答案 7 :(得分：0)
我认为最好的选择不是使用PHP的基本警告系统，而是尽可能使用可用的异常处理。将警告转换为异常，这样您就可以以相同的方式处理所有事情。
您可以捕获特定错误。未被特定处理程序捕获的全局错误可以并且应该由常规处理程序捕获。这样，您可以捕获所有这些错误并在日志中报告和/或将它们邮寄给开发部门（或自己）。
对于用户，您不应在生产环境中显示这些错误，尤其是当它们包含SQL错误或有关缺失变量的消息时。通过显示一些常规内容和一般的，用户友好的错误消息（如果必须），使页面优雅地消失，但保持隐藏技术内容。
但是永远不要忽略或隐藏异常，因为它会使调试成为一个活生生的地狱。