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

Question

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

这是一个艰巨的过程,有数百条通知:

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

由于使用变量假设未定义的变量将只处理为false,如:

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

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

只更换一个变量的实例是相当干净的,就像$_REQUEST['incoming']只查找truthy值一样

@$_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"和朋友的控制权,并可以观察其余代码如何使用它们.