Question

所以我正在努力清理一个可怕的代码库，我正在慢慢转向完整的错误报告。

这是一个艰难的过程，有数百条通知：

Notice: Undefined index: incoming in /path/to/code/somescript.php on line 18

由于使用了变量，假定未定义的变量只会处理为false，如：

if($_SESSION['incoming']){
    // do something
}

目标是能够知道何时引入了错误的未定义变量，使用严格错误/通知检查的能力，作为重构过程的第一个阶段 - 最终将包括重写依赖的代码点以这种方式在标准输入数组上。我知道有两种方法可以替换可能定义或未定义的变量以某种方式抑制通知，如果它尚未定义。

仅仅替换像$_REQUEST['incoming']这样的变量的实例是相当干净的，这些变量只是用

来查找真值

@$_REQUEST['incoming'].

使用“标准”测试替换$_REQUEST['incoming']变量的实例非常脏，这是

(isset($_REQUEST['incoming'])? $_REQUEST['incoming'] : null)

并且你添加了一个三元/内联if，这是有问题的，因为你实际上可以在复杂的代码中以不同方式嵌套parens并完全改变行为。

所以.......与使用@相比，使用(isset($something)? $something : null)错误抑制符号是否有任何不可接受的方面？

编辑：为了尽可能清楚，我不是将“将代码重写为好”与“@”进行比较，由于真正的重构增加了复杂性，这是此过程的后期阶段。我只是比较了我知道的两种方式（可能还有其他方法），用现在的非通知抛出版本替换$ undefined_variable。

Answer 1

另一个选项，似乎适用于在整个地方使用“超级全局”的蹩脚代码，是将全局变量包装在专用数组对象中，具有或多或少的合理[]行为：

class _myArray implements ArrayAccess, Countable, IteratorAggregate
{
     function __construct($a) {
       $this->a = $a;
     }

    // do your SPL homework here: offsetExists, offsetSet etc

    function offsetGet($k) { 
        return isset($this->a[$k]) ? $this->a[$k] : null;
        // and maybe log it or whatever
    }
}

然后

 $_REQUEST = new _myArray($_REQUEST);

通过这种方式，您可以获得对“$ REQUEST”和朋友的控制权，并可以观察其余代码如何使用它们。

Answer 2

如果您对@的使用率进行评分，则需要自行决定。这很难从第三方评价，因为需要知道代码。

但是，看起来您不希望任何错误抑制使代码更容易被您作为需要使用它的程序员访问。

您可以在重新分解您所引用的代码库时创建它的规范，然后将其应用于代码库。

这是您的决定，使用该语言作为工具。

您也可以使用自己的callback function for errors and warnings或scream extension或xdebug's xdebug.scream setting来禁用错误抑制运算符。

Answer 3

你自己回答了你的问题。它可以抑制错误，不会调试它。

Answer 4

在我看来，您应该使用isset()方法正确检查变量。

抑制错误不会使它消失，它只是阻止它显示，因为它本质上说“为此行设置error_reporting(0)”，如果我没记错，它会比检查{{1也是。

如果您不喜欢三元运算符，那么您应该使用完整的if else语句。它可能会使您的代码更长，但更具可读性。

Answer 5

我永远不会在开发服务器上抑制错误，但我会自然地抑制实时服务器上的错误。如果您正在使用实时服务器进行开发，那么您不应该这样做。这对我来说意味着@符号总是不可接受的。没有理由抑制开发中的错误。您应该看到所有错误，包括通知。

@也会让事情变慢，但我不确定isset()是更快还是更慢。

如果您多次写isset()是一件痛苦的事，我会写一个像

这样的函数

function request($arg, $default = null) {
   return isset($_REQUEST[$arg]) ? trim($_REQUEST[$arg]) : $default;
}

只需使用request('var')。

Answer 6

我实际上已经发现了除了这里提到的@之外的另一个警告，我将不得不考虑，这是在处理函数或对象方法调用时，@可以防止错误，即使通过错误杀死脚本，按照这里：

http://us3.php.net/manual/en/language.operators.errorcontrol.php

这是一个非常有力的论据，可以避免在极少数情况下，试图压制变量通知会抑制函数未定义的错误（也许这可能会导致更严重的错误溢出是人们的另一个清音原因）不喜欢@？）。

Answer 7

大多数所谓的“PHP程序员”根本不理解分配变量的整个想法仅仅因为缺乏任何编程教育或背景。

嗯，这与通常的PHP脚本没什么关系，编写了相当大的努力，包含一些HTML / Mysql意大利面和非常少的变量。

另一个问题是更大的代码，当编写相对容易，但调试变成了一场噩梦。当你逐渐理解错误信息是你的朋友，而不是一些令人烦恼和令人不安的事情时，你会学会评价每一条血腥的错误信息，这些事情最好被堵住。

因此，基于这种理解，您将学会在代码中不留下故意错误。
并定义所有变量。
因此，向你的朋友发出错误信息，告诉你出错的地方，找出一些由未初始化的变量引起的难以察觉的错误。

缺乏教育的另一个有趣结果是，10个“PHP程序员”中有9个无法区分错误抑制与关闭显示错误并使用前者代替后者。

是否有任何基本的理由在php中使用isset（）over @

7 个答案: