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

好的;首先,我不相信“错误抑制”是一个解决方案.我(有理由确定我)从未使用过@ error suppress运算符,并且无意这样做.我利用set_error_handler()和ErrorException(或一些派生),我在error_reporting(-1)中开发(未来证明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

当然,如果$data [‘field’]没有在没有索引的情况下返回null来调用offsetGet(),那么我们就会遇到问题.注意遇到异常,异常遇到脚本失败.

我已经尝试了不同的实现,包括使用类似节点的类创建数据树来管理传递给视图的数据列表/行. __get()实际上会创建不存在的节点(在分配或访问时)(为了简化节点数据分配,并防止发出通知.__set()测试有效性,并且会适当地返回false)它还实现了ArrayAccess for访问节点数据,只会在缺失的索引上返回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()转义点并使用error_reporting(-1)保护它们.

我还有其他选择吗？

解决方法:

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

正如您所注意到的,这两个明显的解决方案存在一些开销或缺点.甚至禁用错误报告也会产生一些开销,因为仍然会生成错误(错误消息已格式化,内部和用户错误处理程序被调用等等;它们只是隐藏).这隐藏了你可以从视图中调用的辅助方法的错误;这对调试没有帮助.

我建议你使用模板引擎.有些生成PHP代码与手写代码一样快.他们会为你处理这个问题,并会做更多的事情(比如逃避,你的观点也应该充满htmlspecialchars()调用;)).