20

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

我能找到的最接近答案的是这个问题，但这离我正在寻找的答案还很远。隐藏 PHP 生成的所有通知是否有某种不可预见的缺点？例如，由于出现错误，要将来自 POST 调用的变量包含回表单中，我只需使用：

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

这将生成一个 PHP 通知。要修复该通知，我可以使用以下内容：

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

但是，这真的有必要吗？我的代码是否真的会从这样做中受益，而不仅仅是回显变量是否存在并可能创建 PHP 通知？在我看来，能够忽略通知是使用 PHP 的一个好处，因为这样您就不必担心是否定义了变量，尤其是对于像这样的例子，它似乎并不重要。

我还利用 PHP 的能力，根据变量的使用方式自动更改变量的类型/转换，您经常会发现如下代码片段：

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

where$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

4 回答 4

23

在我看来，你永远不应该压制错误，任何类型的错误，通知与否。它现在可能会给您带来一些便利，但在以后的路上，您在维护代码时会遇到很多很多问题。

假设您有一个想要回显的变量，就像上面的第一个示例一样。是的，使用 isset 有点复杂，但也许您的应用程序无论如何都应该处理特殊的空情况，从而改善体验。例子：

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

如果您只有echo $var;并且如果这是用户正在阅读的面向公众的视图，那么他们将在那里什么也看不到，这可能会引起混乱。当然，这只是修复 PHP 通知可以改进您的应用程序的一种特殊情况。

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

同样，错误（即使它们不是致命的）会在未来引起问题。如果您已经在echo $var;不检查它的情况下进行操作，则假设变量存在，即使您知道它可能不存在，它也会让您养成假设事物存在并且有效的习惯。这现在可能很小，但过一段时间你会发现你会给自己带来很多很多问题。

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

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

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

于 2011-08-19T01:59:16.323 回答
4

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

恕我直言，不应忽视警告。您应该始终注意警告以防止错误。每次我在日志文件中看到通知时，我都会将其视为错误。

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

于 2011-08-19T01:59:21.673 回答
3

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

当然，计算机并不是那么聪明，在某些情况下代码足够清晰，你不在乎是否有任何警告，但这就是@操作员的目的。

于 2011-08-19T02:06:19.677 回答
3

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

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-tests 来膨胀代码有点愚蠢。

当然，如果我没记错的话，使用 @ 会花费更多时间来执行 isset 测试，但老实说：我们的代码中有多少是真正对性能至关重要的？在一个执行了无数次的循环中，我可能会改用 isset，但在大多数情况下，它对用户没有任何影响。

于 2014-10-06T15:43:16.447 回答