E_NOTICE：修复每个问题真的有用吗？ [英] E_NOTICE: How useful is it REALLY to fix every one?

问题描述

首先，我知道这个问题在这里已经多次出现：

First off I know this question has gone around more than once here:

• 为什么要修复E_NOTICE错误？


• 为什么要修复E_NOTICE错误？优点和缺点

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

但是我修复所有E_NOTICE的次数越多（正如人们所说的那样），我越注意到：

But the more that I fix all E_NOTICEs (as people say you should) the more I notice that:

• 我正在微优化


• 我实际上是在编写更多代码，并使我的代码更难维持和减慢速度

以示例为例：

使用MongoDB PHP驱动程序，您在一个类中的 MongoDate 对象中有一个 ts 对象，该类代表数据库中的集合。现在，您可以像下面这样访问该变量： $ obj-> ts-> sec ，但是PHP会抛出一个错误（E_NOTICE），因为 ts 本身未定义为对象，因为该特定行没有 ts 字段。因此，您认为这是可以的，这是期望的行为，如果未将其设置为return null，那么我将在解释器自身的机器人工作之外亲自进行处理（因为您将其包装在 date（）函数，如果var是 null 或，则仅返回 1970 无对象）。

Say your using the MongoDB PHP driver and you have a MongoDate object in a class var named ts within a class that represents a single row in a collection in your database. Now you acces this var like: $obj->ts->sec but PHP throws a fit (E_NOTICE) because ts in this case is not defined as an object in itself because this particular row does not have a ts field. So you think this is OK, this is desired behaviour, if it's not set return null and I will take care of it myself outside of the interpreters own robotic workings (since you wrap this in a date() function that just returns 1970 if the var is null or a none-object).

但是现在要解决这个问题，因为另一个开发人员确实希望我这样做，因为拥有任何E_NOTICE都是很糟糕的事情，代码较慢，无法根据错误执行此操作。因此，我在 $ obj 类中创建了一个名为 getTs 的新函数，然后给它3行，实际上什么也没做但是请检查 ts 变量是否为 MongoDate 对象，如果是，则将其返回...

But now to fix that E_NOTICE as another developer really wants me to since having ANY E_NOTICEs is terribad and it makes the code slower to not do it according to the errors. So I make a new function in the $obj class called getTs and I give it 3 lines, literally to do nothing but check if the ts var is a MongoDate object and return it if it is...

为什么？用它更快的解释器，PHP是否比在应用程序本身的运行时中做到这一点对我来说完美？我的意思是，每当我不得不在代码中添加无用的颠簸时，就会发现很多空函数来检测我实际上只是使用PHP自身返回 null 的能力来处理的变量或检查它们 instanceof 当我确实需要（当对所述函数的操作和行为至关重要时）并且不让我开始使用 isset时（） s我添加了大约300行 isset（） s，它已经失控了。我当然要使用此 getTs 函数，因为您不能这样做：

WHY? Can't PHP do this perfectly fine for me within its much faster interpreter than having to do it within the runtime of the app itself? I mean every where I am having to add useless bumpth to my code, pretty much empty functions to detect variables that I actually just handle with PHPs own ability to return null or checking their instanceof when I really need to (when it is vital to the operation and behaviour of the said function) and don't get me started on the isset()s I have added about 300 lines of isset()s, it's getting out of hand. I have of course got to make this getTs functions because you can't do:

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

我要么要存储 ts，要么 __ constructor 中的code>（对此我也不是很高兴，我正在使用很多魔术）或使用一个函数来检测它是否设置（我现在要进行设置）。

I would either have to store the ts within the __constructor (which I am not too happy about either, I am using a lot of magics as it is) or use a function to detect if it's set (which I do now).

我的意思是我明白为什么要修复：

I mean I understand why I should fix:

• 未定义的变量


• 分配未设置变量的属性（ null 变量）


• 持续错误等

• Undefined vars
• Assigning properties of unset vars (null vars)
• constant errors etc

但是如果您已经测试过代码，并且知道它是安全的，并且只能按照您期望的方式工作，修复所有未定义索引或无对象错误？实际上不是在代码中添加一堆 isset（） s和2行函数吗？

But if you have tested your code and you know it is safe and will only work the way you desire what is the point in fixing all of the undefined index or none-object errors? Isn't adding a bunch of isset()s and 2 lines functions to your code actually micro-optimisation?

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

I have noticed after making half my site E_NOTICE compliant that actually it uses more CPU, memory and time now...so really what's the point of dealing with every E_NOTICE error and not just the ones that ARE errors?

感谢您的想法，

推荐答案

您是否应该修复它们肯定值得商bat ，而这仅取决于您所处情况的回报；例如，如果代码具有更长的使用寿命，更多的开发人员等，就更重要。

Whether or not you should fix them is certainly debatable, and will just depend on the return in your situation; eg, it's more important if the code will have a longer life-span, more devs, etc.

通常，假设您的函数将被使用（并且错误地-最好由其他人使用），因此您应该进行isset /！empty / is_object检查以解决此问题。通常，您的代码会发现它进入了您从未想要的用途和情况的方式。

In general, assuming that your functions will be used (and mis-used) by someone else is the best practice, so you should do isset/!empty/is_object checks to account for this. Often, your code will find it's way into uses and situations you never intended it for.

就性能而言，每次抛出任何类型的错误-包括E_NOTICE -解释器启动错误处理程序，构建堆栈跟踪并格式化错误。关键是，无论您是否报告错误，错误始终会降低执行速度； 因此， 2-3个避免E_NOTICE的函数调用仍会改善您的性能。

As far as performance, Every time any kind of error is thrown--E_NOTICE included--the interpreter spins up the error handler, builds a stack trace, and formats the error. The point is that, whether or not you have them reporting, errors always slow execution; therefore, 2-3 function calls to avoid an E_NOTICE will still improve your performance.

编辑：
上面示例的替代方案

Alternatives for the above example

我不会必须创建额外的对象以避免错误；您可以优雅地避免它们。以下是几个选项：

I wouldn't necessarily create extra objects to avoid the errors; you can gracefully avoid them without. Here are a couple of options:

1）处理丢失的ts的函数：

1) Function that handles missing ts:

SpecialClass class {

    funciton getTs () {
        return !empty($this->ts) ? $ts->sec : false;
    }
}

2）处理模板/过程中缺少的ts：

2) Deal with missing ts in template/procedure:

if (!empty($obj->ts->sec)) {
    //do something
}

我特别喜欢 empty（），因为您可以使用它替换（isset（$ var）&&（$ var或0！= $ var // etc））多次调用/比较且为空，则永远不会对目标var或属性发出通知。如果您在不存在的变量的属性/成员上调用它，则会引发错误。

I particularly like empty() because you can use it to replace of (isset($var) && ($var or 0 != $var //etc)), saving multiple calls/comparisons and empty never throws notices for the target var or attribute. It will throw an error if you're calling it on a proptery/member of a non-existent variable.

这篇关于E_NOTICE：修复每个问题真的有用吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！