PHP通知抑制;只有某些情况/方法 [英] PHP notice supression; only certain circumstances/methods

问题描述

tl; dr - 在非常严格的环境中工作时，是否有有效的方法来管理PHP的错误报告级别，因为某些流程将以较不严格的级别？

tl;dr - Is there an effective way to manage the error reporting level of PHP when working in a very strict environment, given certain processes would be made easier with a less strict level?

好的;首先，我不相信错误抑制是一个解决方案。我（我确信我）从未使用过 @ 错误抑制运算符，无意这样做。我利用 set_error_handler（）和 ErrorException （或某些派生的）和我开发 error_reporting（-1）（未来证明 E_ALL | E_STRICT ）

Alright; first off, I don't believe "error suppression" is a solution. I (am reasonably certain that I) have never used the @ error supression operator, and have no intention of doing so. I take advantage of set_error_handler() and ErrorException (or some derivation of) and I develop in an error_reporting(-1) (future proof E_ALL | E_STRICT)

现在，我不想改变这些习惯，因为我发现他们是一个很好的做法（如果有人有进一步改进我的开发/生产的建议）环境设置/实践，我都是耳朵）

Now, I don't want to change these habits, as I find they are a great practice (also; if anyone has suggestions to further improve my development/production environment settings/practices, I'm all ears)

然而，当涉及到视图生成时，这可能会变得有点乏味。由于无论什么原因，由于控制器无法将某些数据传递到视图，所以正确的数据（<数组索引，变量等）并不总是可用的。只要这些数据对查看生成是非关键的，视图应该仍然呈现。

However, when it comes to view generation this can get slightly tedious. The correct data (array indices, variables, etc.) are not always available, given a controller fails to pass certain data to the view for whatever reason. As long as this data is non-critical to view generation, the view should still render.

我更喜欢这种语法，因为它不是冗长的（我认为）高度可理解：

I rather like this syntax as it's not verbose but (I think) highly understandable:

// 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 没有索引返回，我们有一个问题。注意遇到异常，异常遇到脚本失败。

Of course, if $data['field'] isn't invoking offsetGet() with null returned in absence of the index, we have a problem. Notice meet exception, exception meet script failure.

我已经尝试过不同的实现，包括使用类似节点的类创建数据树来管理列表/数据行传递给观点。 __ get（）将实际创建不存在的节点（分配或访问）为了简化节点数据分配，并且防止发出通知。 __ isset（）经过测试的有效性，并会适当地返回 false ）它还实现了 ArrayAccess 来访问节点数据，并且将简单地在缺少的索引上返回 null

I've experimented with different implementations, including creating a data tree using a node-like class to manage lists/rows of data passed to the view. __get() would actually create nodes (on assignment or access) that don't exist (as to simplify node data assignment, and to prevent issuing notices. __isset() tested for validity and would return false appropriately though) It also implemented ArrayAccess for accessing the node data, and would simply return null on a missing index.

由于PHP的魔法开销（尽管我学到了很多关于重构/优化和分析的方式），我已经选择放弃了这个实现。

I've opted to abandon this implementation due to the overhead of PHP's magic (though I learned alot about refactoring/optimization and profiling)

我已经使用本机数组了，但现在我的意见的代码库是带有 isset（） ，坦率地说，这只是激怒（几乎比上述实施的绩效损失）

I've gone with native arrays instead, but now the codebase for my views is littered with isset(), and frankly that's just irritating (nearly more than the performance loss of the aforementioned implementation)

现在，我认为最简单的修复是将 error_reporting（）上下滑动基于我们在脚本中的位置：

Now, I was thinking the easiest fix would be to slide the error_reporting() notch up and down based on where we are in the script:

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

但这似乎不是最干净的（ / em>）修复;特别是在视图中调用辅助函数时。我已经采用了一种HMVC方法，并且可以从一个视图中发出子请求，所以我需要找到所有的 render（）转义点和使用 error_reporting（-1）保护他们。

But that doesn't seem like the cleanest (nor safest) fix; especially when helper functions are called within a view. I've gone for a sort of HMVC approach, and sub-requests can be issued from a view, so I'd need to find all the render() escape points and guard them with error_reporting(-1).

我有其他选项吗？

推荐答案

undefined变量通知非常有价值，即使在视图模板中，因为它们有助于发现错别字;但是这需要定义控制器中的每个变量，或者检查它们是否在视图中设置。

"undefined variable" notices are very valuable, even in view templates, as they help to spot typos; but this requires to either define every variable in the controllers, or to check if they are set in views.

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

As you noticed, the two obvious solutions have some overhead or drawbacks. Even disabling error reporting has some overhead since errors are still generated (the error message is formatted, internal and user error handlers are called, etc; they are just hidden). And this hides errors from helper methods you may call from the views; this doesn't helps debugging.

我会建议您使用模板引擎。有些生成PHP代码与手写代码一样快。他们会为你处理这个事情，并且会做更多的事情（像转义一样，你的意见也应该用htmlspecialchars（）调用;））。

I would recommand you to go with a template engine. Some generate PHP code as fast as hand-written code. They will handle this for you, and will do more (like escaping, your views should also be littered with htmlspecialchars() calls ;) ).

这篇关于PHP通知抑制;只有某些情况/方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！