PHP通知抑制;仅某些情况/方法

问：

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

好;首先，我不认为“错误抑制”是一种解决方案。我（有理由确定我）从未使用过错误抑制运算符，也无意这样做。我利用和（或一些衍生物），并在（面向未来的E_ALL |E_STRICT@set_error_handler()ErrorExceptionerror_reporting(-1))

现在，我不想改变这些习惯，因为我发现它们是一个很好的实践（而且;如果有人有进一步改进我的开发/生产环境设置/实践的建议，我会全神贯注)

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

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

// 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>

当然，如果在没有索引的情况下没有调用 with returned，我们就有问题了。注意 meet 异常，exception meet 脚本失败。$data['field']offsetGet()null

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

由于PHP的魔力开销，我选择放弃这个实现（尽管我学到了很多关于重构/优化和分析的知识)

我改用了原生数组，但现在我的观点的代码库中充斥着 ，坦率地说，这很烦人（几乎比上述实现的性能损失还要多isset())

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

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

但这似乎不是最干净（也不是最安全）的解决方法;尤其是在视图中调用帮助程序函数时。我采用了一种 HMVC 方法，可以从视图发出子请求，因此我需要找到所有逃逸点并用 .render()error_reporting(-1)

我还有其他选择吗？