php - E_NOTICE : How useful is it REALLY to fix every one?

Question

首先我知道这个问题在这里不止一次出现过:

• Why should I fix E_NOTICE errors?
• Why should I fix E_NOTICE errors? Pros and cons

但是我修复所有 E_NOTICE 的次数越多(正如人们所说的那样)，我就越注意到:

• 我正在微优化
• 我实际上正在编写更多代码并使我的代码更难维护且速度更慢

举个例子:

假设您使用 MongoDB PHP 驱动程序并且您有一个 MongoDate名为 ts 的类 var 中的对象在代表数据库集合中的单行的类中。现在你像这样访问这个变量:$obj->ts->sec但是 PHP 抛出了一个合适的 (E_NOTICE) 因为 ts在这种情况下，它本身未定义为对象，因为该特定行没有 ts field 。所以你认为这没关系，这是期望的行为，如果它没有设置返回 null，我会在解释器自己的机器人工作之外自己处理它(因为你将它包装在一个 date() 函数中，它只返回 1970如果 var 是 null 或 none-object )。

但现在要像另一个开发人员真正希望我那样修复 E_NOTICE，因为有任何 E_NOTICE 都是非常糟糕的，并且如果不根据错误执行它会使代码变慢。所以我在 $obj 中创建了一个新函数类名为 getTs我给它 3 行，字面意思是除了检查 ts 之外什么都不做。 var 是一个 MongoDate对象并返回它，如果它是...

为什么？难道 PHP 不能在其更快的解释器中为我做这件事，而不是在应用程序本身的运行时做这件事吗？我的意思是我必须在我的代码中添加无用的颠簸，几乎是空函数来检测我实际上只是用 PHP 自身返回能力处理的变量 null或查看他们的 instanceof当我真的需要时(当它对上述功能的操作和行为至关重要时)并且不要让我开始 isset()我添加了大约 300 行 isset() s，它失控了。我当然得做这个getTs功能，因为你不能这样做:

class obj{
    public $ts = new MongoDate();
}

我要么必须存储 ts在 __constructor 内(我对此不太满意，我正在使用很多魔法)或使用函数来检测它是否已设置(我现在这样做)。

我的意思是我理解为什么我应该修复:

• undefined variable
• 分配未设置变量的属性(null 变量)
• 常有错误等

但是，如果您已经测试了您的代码并且您知道它是安全的并且只会按照您希望的方式工作，那么修复所有 undefined index 的意义何在？或 none-object错误？是不是添加了一堆 isset() s 和 2 行函数实际上对您的代码进行了微优化？

在使我的一半网站符合 E_NOTICE 标准后，我注意到实际上它现在使用了更多的 CPU、内存和时间...那么处理每个 E_NOTICE 错误而不仅仅是那些错误的真正意义何在？

谢谢你的想法，

Answer 1

通过使用 isset()，您确实确实获得了更好的性能。不久前，我做了一些基准测试，结果只是隐藏错误的速度大约慢了 10 倍。

http://garrettbluma.com/2011/11/14/php-isset-performance/

也就是说，性能通常不是 PHP 的关键因素。 做，个人让我发疯的是无提示错误。

当解释器选择不将某事标记为错误(这可能导致不稳定)时，这是一个巨大的问题。 PHP 尤其倾向于

• 警告应该错误的事情(例如，无法连接到数据库)和
• 就应该警告的事情发出通知(例如，试图访问空对象的成员)。

也许我只是对这类事情过于自以为是，但我以前曾被这些无声的错误所困扰。 我建议始终在错误报告中包含 E_NOTICE。