4

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

好的; 首先，我不相信“错误抑制”是一种解决方案。我（有理由确定我）从未使用过@错误抑制运算符，也无意这样做。我利用set_error_handler()and 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
<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()逃生点并用error_reporting(-1).

我还有其他选择吗？

4

2 回答 2

3

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

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

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

于 2011-08-14T20:25:40.940 回答
1

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

是的，这是一个极端的解决方案，但它是一个紧要关头的选择。显然，您需要在生产环境中使用官方构建。

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

于 2014-10-31T23:26:11.030 回答