Why Should I Fix E_Notice Errors

Why should I fix E_NOTICE errors?

SUMMARY

The PHP Runtime Configuration Docs give you some idea why:

Enabling E_NOTICE during development has some benefits.

For debugging purposes: NOTICE messages will warn you about possible bugs in your code. For example, use of unassigned values is warned. It is extremely useful to find typos and to save time for debugging.

NOTICE messages will warn you about bad style. For example, $arr[item] is better to be written as $arr['item'] since PHP tries to treat "item" as constant. If it is not a constant, PHP assumes it is a string index for the array.

Here's a more detailed explanation of each...

---

1. TO DETECT TYPOS

The main cause of E_NOTICE errors is typos.

Example - notice.php

<?php
$username = 'joe';        // in real life this would be from $_SESSION

// and then much further down in the code...

if ($usernmae) {            // typo, $usernmae expands to null
    echo "Logged in";
}
else {
    echo "Please log in...";
}
?>

Output without E_NOTICE

Please log in...

Wrong! You didn't mean that!

Output with E_NOTICE

Notice: Undefined variable: usernmae in /home/user/notice.php on line 3
Please log in...

In PHP, a variable that doesn't exist will return null rather than causing an error, and that could cause code to behave differently than expected, so it's best to heed E_NOTICE warnings.

---

2. TO DETECT AMBIGUOUS ARRAY INDEXES

It also warns you about array indexes that might change on you, e.g.

Example - code looks like this today

<?php

$arr = array();
$arr['username'] = 'fred';

// then further down

echo $arr[username];
?>

Output without E_NOTICE

fred

Example - tomorrow you include a library

<?php
// tomorrow someone adds this
include_once('somelib.php');

$arr = array();
$arr['username'] = 'fred';

// then further down

echo $arr[username];
?>

and the library does something like this:

<?php
define("username", "Mary");
?>

New output

Empty, because now it expands to:

echo $arr["Mary"];

and there is no key Mary in $arr.

Output with E_NOTICE

If only the programmer had E_NOTICE on, PHP would have printed an error message:

Notice: Use of undefined constant username - assumed 'username' in /home/user/example2.php on line 8
fred

---

3. THE BEST REASON

If you don't fix all the E_NOTICE errors that you think aren't errors, you will probably grow complacent, and start ignoring the messages, and then one day when a real error happens, you won't notice it.

Why should I fix E_NOTICE errors? Pros and cons

When I look at your code, for example

$this->_oldattributes['category_id']

my first thought was, that this should probably be a class instead.

class Attributes {
  public $categoryId;
  // and so on
}

The difference now is, that don't need to use isset() anymore, because now the property exists (maybe it's null) or it is definetely a bug ("Undefined property") and should be fixed. I think most of your cases, that you "fixed" with isset(), are of this kind.

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

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.

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.

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.

Edit:
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) Function that handles missing ts:

SpecialClass class {

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

2) Deal with missing ts in template/procedure:

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

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.

PHP error_reporting either on or off

I would say there is probably another page or script that is being included that is setting error_reporting to a different value. You can call error_reporting() with no args to get the current value. Set it to something and check that the value hasn't changed after including other files.

What are differences between error_reporting(E_ALL) and error_reporting(E_ALL & ~E_NOTICE)

E_ALL is "everything"

E_ALL & ~E_NOTICE is "everything except notices"

Notices are the least-urgent kinds of messages. But they can be very useful for catching stupid programmer mistakes, like trying to read from a hash with a non-existent key, etc.

(To understand the syntax, read up on bitwise operators)

Should PHP 'Notices' be reported and fixed?

Errors are errors. They have to be fixed before your code works.

Warnings are warnings. They warn you that what you're doing is probably a bad idea, even if it works (or seems to work) for you at the moment. So they too should probably be fixed.

Notices are notices. They should be noticed. Hence the name. It may not be a problem that your code generates some, but it's something you should examine and judge on a case-by-case basis.

And of course, it is much easier to notice notices if you don't get 400 of them. So there's a big benefit to trying to eliminate them. It makes the ones you haven't yet noticed become more noticeable.

PHP Error Reporting Production vs Development

Quoting the php-production.ini that should have come bundled with your PHP:

; PHP comes packaged with two INI files. One that is recommended to be used
; in production environments and one that is recommended to be used in
; development environments.

; php.ini-production contains settings which hold security, performance and
; best practices at its core. But please be aware, these settings may break
; compatibility with older or less security conscience applications. We
; recommending using the production ini in production and testing environments.

and further

; display_errors
;   Default Value: On
;   Development Value: On
;   Production Value: Off

; display_startup_errors
;   Default Value: Off
;   Development Value: On
;   Production Value: Off

; error_reporting
;   Default Value: E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED
;   Development Value: E_ALL
;   Production Value: E_ALL & ~E_DEPRECATED & ~E_STRICT

; html_errors
;   Default Value: On
;   Development Value: On
;   Production value: On

; log_errors
;   Default Value: Off
;   Development Value: On
;   Production Value: On

Since you asked for best practise, I suggest you go with that.

Is the following the correct way to disable both E_WARNING and E_NOTICE in PHP

That would do what you describe (turn off warnings and notices), yes. But if you actually want to turn off everything—which is highly recommended in production code—just use error_reporting(0);. There are many types of errors, warnings, and notices defined in PHP—and thus included in E_ALL^*—that are not covered by E_NOTICE or E_WARNING.

From the docs

PHP 5.3 or later, the default value is E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED. This setting does not show E_NOTICE, E_STRICT and E_DEPRECATED level errors. You may want to show them during development. Prior to PHP 5.3.0, the default value is E_ALL & ~E_NOTICE & ~E_STRICT. In PHP 4 the default value is E_ALL & ~E_NOTICE.

^{As of 5.4, all errors, notices, and warnings covered by any predefined E_* constant are included in E_ALL. See the docs.}

How do I turn off PHP Notices?

You can disable notices by setting error reporting level to E_ALL & ~E_NOTICE; using either error_reporting ini setting or the error_reporting() function.

However, notices are annoying (I can partly sympathize) but they serve a purpose. You shouldn't be defining a constant twice, the second time won't work and the constant will remain unchanged!

---

Related Topics