php error reporting set up usually to be E_ALL & ~E_NOTICE.

When we do the programming, should we make the codes works for "E_ALL & ~E_NOTICE or E_ALL"?

Or should we be more strict?

make the codes to works for "E_ALL"

Of course, in theory, more strict like "E_ALL" is better, but many systems make it work with "E_ALL & ~E_NOTICE or E_ALL"?

What is the best balance point in your opinions?

Thanks!

    I prefer using both E_ALL | E_STRICT via error_reporting(E_ALL | E_STRICT);
    So, in other words, I develop for both in mind.

    The problem with using only say E_ALL (or E_NOTICE) is that it won't catch issues like this for instance:

    class Dog {
	function bark(){
		echo 'Woof!';
	}
}

Dog::bark();

    In this case, trying to call a method statically while the method is not statically declared will still execute, but if only using E_ALL / E_NOTICE, you won't see the juicy Strict Standards warning that comes along with this.

      Aim to make it work for E_ALL (or E_ALL|E_STRICT): that's your benchmark. Once you're live, E_ALL & ~E_NOTICE is acceptable because you don't want your error logs swamped by those last few Notices that you could not eliminate from normal activity without totally reworking everything (you do log those messages right? You don't display them?).

      That's why php.ini is distributed in two flavours.

        Weedpacket;10918794 wrote:

        Aim to make it work for E_ALL (or E_ALL|E_STRICT): that's your benchmark. Once you're live, E_ALL & ~E_NOTICE is acceptable because you don't want your error logs swamped by those last few Notices that you could not eliminate from normal activity without totally reworking everything (you do log those messages right? You don't display them?).

        That's why php.ini is distributed in two flavours.

        If you happen to use any libraries that were not written with E_STRICT in mind it can be a painful experience 🙂

        Since we use PEAR a fair bit E_ALL is usually the standard reporting level.

          Write a Reply...