PHP通知抑制；仅在某些情况/方法下

Question

tl;dr - 在非常严格的环境中工作时，是否有一种有效的方法来管理 PHP 的错误报告级别，因为某些过程会变得更容易不太严格的级别？

好吧；首先，我不相信“错误抑制”是一个解决方案。我（相当确定我）从未使用过 @ 错误抑制运算符，并且无意这样做。我利用 set_error_handler() 和 ErrorException （或其派生），并在 error_reporting(-1)< 中进行开发/code> （面向未来E_ALL | E_STRICT）

现在，我不想改变这些习惯，因为我发现它们是一个很好的实践（还有；如果有人有建议为了进一步改进我的开发/生产环境设置/实践，我洗耳恭听）

但是，当涉及到视图生成时，这可能会有点乏味。如果控制器出于某种原因无法将某些数据传递到视图，则正确的数据（数组索引、变量等）并不总是可用。只要此数据对于视图生成不重要，视图仍应呈现。

我更喜欢这种语法，因为它并不冗长，但（我认为）非常容易理解：

// e() is a shortcut function; given the passed value evaluates to a boolean true
// it will echo() and return true, otherwise it simply returns false
<p><?php e($data['field']) or e('No data found'); ?></p>

当然，如果 $data['field'] 没有调用 offsetGet () 并在缺少索引的情况下返回 null，我们遇到了问题。通知遇到异常，异常遇到脚本失败。

我尝试了不同的实现，包括使用类似节点的类创建数据树来管理传递到视图的数据列表/行。 __get() 实际上会创建不存在的节点（在分配或访问时）（为了简化节点数据分配，并防止发出通知。__isset()测试了有效性，并且会适当地返回false）它还实现了ArrayAccess来访问节点数据，并且在缺失时简单地返回 null 指数。

由于 PHP 魔法的开销，我选择放弃这个实现（虽然我学到了很多关于重构/优化和分析的知识），但

我已经使用了原生数组，但现在我的观点的代码库与 isset() 乱七八糟，坦率地说，这只是令人恼火（几乎超过上述实现的性能损失）

现在，我我认为最简单的修复方法是根据我们在脚本中的位置上下滑动 error_reporting() 缺口：

// View::render()
public function render($data){
    error_reporting(E_ALL & ~E_NOTICE);
    // view generation logic
    error_reporting(-1);
}

但这似乎不是最干净的（也不是最安全的) 修复；特别是在视图中调用辅助函数时。我采用了一种 HMVC 方法，并且可以从视图发出子请求，因此我需要找到所有 render() 转义点并使用 保护它们错误报告（-1）。

我还有其他选择吗？

Answer 1

“未定义的变量”通知非常有价值，即使在视图模板中也是如此，因为它们有助于发现拼写错误；但这需要定义控制器中的每个变量，或者检查它们是否在视图中设置。

正如您所注意到的，这两个明显的解决方案都有一些开销或缺点。即使禁用错误报告也会产生一些开销，因为错误仍然会生成（错误消息被格式化，内部和用户错误处理程序被调用等；它们只是被隐藏）。这隐藏了您可能从视图调用的辅助方法中的错误；这对调试没有帮助。

我建议您使用模板引擎。有些生成 PHP 代码的速度与手写代码一样快。他们会为你处理这个问题，并且会做更多的事情（比如转义，你的视图也应该充斥着 htmlspecialchars() 调用;)）。

Answer 2

继续报告E_NOTICE，这是值得的。也就是说，我同意未定义索引与未定义变量的错误程度不同，并且isset($options['boolean_flag']) && $options['boolean_flag'] 有点难看。我从事的一个项目有数千个这样的通知，因此为了不断看到 E_NOTICE 级别的错误而不被未定义索引淹没，我实际上重新编译了语言以忽略该错误特定类型的通知。 （我使用的是 HHVM 而不是 PHP，但它们是相同的区别）。

是的，这是一个极端的解决方案，但它是一个紧要关头的选择。显然，您需要使用官方的生产版本。

注意：我写下了重新编译的步骤，如果有人想尝试，可以将其发布，但这有点超出了原始问题的范围。