抑制/隐藏PHP通知是否可以?

时间:2011-08-19 01:49:40

标签: php suppress-warnings notice

我已经压制了很长一段时间没有任何问题的通知,但我开始怀疑我做的是否正确。我似乎无法找到任何合理的理由,为什么我不应该只是压制它们,但是其他一些人似乎认为使用error_reporting来抑制它们是一件可怕的事情,但为什么呢?

我能找到的答案最接近的是this question,但这仍然远不是我正在寻找的答案。隐藏PHP生成的所有通知是否存在某种无法预料的缺点?例如,要将POST调用中的变量包含回表单中,因为存在错误,我只需使用:

<?= $_POST['variable'] ?>

这将生成PHP通知。为了解决这个问题,我可以使用这样的东西:

<?= isset($_POST['variable']) ? $_POST['variable'] : '' ?>

但是,这真的有必要吗?我的代码实际上是否会从中获益,而不仅仅是回显变量是否存在并可能创建PHP通知?在我看来,能够忽略通知是使用PHP的好处,因为您不必担心变量是否被定义,特别是对于这样的例子,它似乎并不重要。

我还利用PHP能够自动更改变量的类型/强制转换,具体取决于它的使用方式,您经常会找到这样的代码片段:

for ($i = 0; $i < $limit; $i++) $results[] = $i; // Example

其中$results之前没有定义过,但当我尝试将新项目作为数组添加到数组时会变成数组。我更喜欢这样做,因为如果没有结果添加到数组并且我需要存储该信息或者出于任何原因将其转换为JSON,那么将不会定义该特定变量,从而节省额外的带宽,即使它是分钟。

$data = stdClass; // For reference, in my case this would be defined before this code
$data->results = array();
$limit = 0;
for ($i = 0; $i < $limit; $i++) $data->results[] = $i;
print json_encode($data);
// {"results":[]}

$data = stdClass; // For reference
$limit = 0;
for ($i = 0; $i < $limit; $i++) $data->results[] = $i;
print json_encode($data);
// []

再次提出这个问题:如果有什么真正的好处,我可以从修正通知错误中获得而不仅仅是抑制它们?怎么会/会伤害我的代码?

4 个答案:

答案 0 :(得分:24)

在我看来,你永远不应该压制错误,任何类型的错误,通知与否。它现在可能会为您提供一些便利,但是在您维护它时,您的代码会遇到很多很多问题。

假设您有一个想要回显的变量,就像上面的第一个例子一样。是的,使用isset有点复杂,但也许你的应用程序应该处理特殊的空案例,从而改善体验。示例:

if (isset($var)) {
    echo $var;
} else {
    echo "Nothing is found. Try again later.";
}

如果您只有echo $var;并且如果这是一个用户正在阅读的公众视图,他们只会看到任何内容,这可能会导致混淆。当然,这只是一个特殊情况,修复PHP Notices可以改善您的应用程序。

当您在PHP代码中处理通知时,不应将其视为麻烦或不便,因为代码应该是干净的。当我在源代码中打开它时,我宁愿拥有一个没有通知的代码而不是看到干净的代码。当然,两者肯定更好! :)

同样,错误(即使它们不是致命的)也会导致问题。如果你已经在做echo $var;这样的事情而没有检查它,那就是假设一个变量存在,即使你知道它可能不存在,它只会给你一个习惯假设的东西存在和工作。这可能现在很小,但过了一段时间,你会发现你会给自己造成很多很多问题。

通知是有原因的。如果我们在代码中都error_reporting(E_ALL ^ E_NOTICE),我们的代码只是不负责任。如果你能够解决它,那你为什么懒惰而不这样做呢?当然,发布1.0的通知,稍后修复它们,这就是我们所说的。但最好这样做是一种习惯,代码第一次完美。如果您花15分​​钟编写受通知困扰的代码,然后在以后的开发时间花费2个小时修复,为什么不花一个半小时来完善代码,因为您在第一时间编写代码?

编写好的代码应该是一种习惯,而不是一种不便。 错误消息是有原因的。尊重他们,修复他们,你去,你是一个负责任的程序员。

您还为未来的代码维护者铺平了道路。

答案 1 :(得分:4)

假设您有一个不应忽视的通知。 此通知将隐藏在您经常忽略的所有通知中。

恕我直言,警告不应该被忽视。您应该始终注意警告以防止错误。每当我在日志文件中发出通知时,我都会将其视为一个错误。

此外,如果您的网站被很多用户访问,您将获得一个非常大的日志文件。

答案 2 :(得分:3)

根据我的经验,通知通常表明代码中某处存在错误的可能性很大,通常情况下,您希望某个变量设置在某个特定点,但有时会出现错误,并且你会开始想知道为什么你的页面的某些部分没有显示或开始随机崩溃。

当然,计算机并不是那么聪明,并且会出现代码足够清晰并且您不关心是否有任何警告的情况,但这就是@运算符的用途。< / p>

答案 3 :(得分:2)

我恭敬地不赞同一些建议你永远不应该压制通知的评论。如果您知道自己在做什么,我认为使用@非常有用,特别是对于处理未设置的变量或数组元素。不要误会我的意思:我同意在一个没有经验或邋program的程序员的手中,@可能是邪恶的。但是,请考虑以下示例:

public function foo ($array) {
    if (isset ($array[0])) {
        $bar = $array[0];
    } else {
        $bar = null;
    }

    // do something with $bar
}

在功能上与

相同
public function foo ($array) {
    $bar = @$array[0];

    // do something with $bar
}

但恕我直言的可读性较差,打字工作也较多。在这些类型的情况下,我知道有两种可能性:变量设置或不设置。我事先不知道,但我必须在两种情况下进行。在这种情况下,我认为使用@没有任何问题。是的,你也可以写

public function foo ($array) {
    $bar = isset ($array[0]) ? $array[0] : null;

    // do something with $bar
}

但我发现这只是略微好一些。对我来说,代码的可读性和简洁性本身就是价值,并且使用isset-test对代码进行膨胀是非常愚蠢的。

当然,如果我没有弄错的话,使用@需要花费更多的时间来执行isset-test,但是说实话:我们的代码中有多少是真正的性能关键?在一个执行了数万次的循环中,我可能会使用isset,但在大多数情况下,它对用户没有任何影响。