Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:28049
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain l-i-e.com from 67.139.134.202 cause and error)
Message-ID: <60597.216.230.84.67.1171588117.squirrel@www.l-i-e.com>
Date: Thu, 15 Feb 2007 19:08:37 -0600 (CST)
To: internals@lists.php.net
Reply-To: ceo@l-i-e.com
User-Agent: Hostbaby Webmail
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [PHP-DEV] Suggestion: global variables being accessed in       
                             localscope
From: ceo@l-i-e.com ("Richard Lynch")

[Taking this back on-list, as it's my final answer.]

On Wed, February 14, 2007 5:30 pm, Christian Schneider wrote:
> Richard Lynch wrote:
>> But the code that checks for E_NOTICE also has to be altered to check
>> for E_STRICT...
>
> How many applications use error handlers. And how many of them rely
on a
> specific code being a specific level? Out of curiousity: I wouldn't
even
> know why someone would do something like that, perhaps you have a
good example.
>
> Anyway, that's a BC break I find worth doing but I'm fully aware
that you will disagree.

Anybody on shared hosting who wants to log their errors somewhere out
of the morass of system logs without dinking around with .htaccess is
going to use set_error_handler.

For that matter, if .htaccess is off, and you can't edit php.ini,
set_error_handler is just about your only option for reasonable error
handling.

I think you will find that a LOT of distributed applications use this
to avoid splatting PHP error messages out.  Or, at least, they should
be using it, as there's no other way without using something you can't
rely on if your code is widely distributed in unknown environments.

I know *I* have used it more than a few times.

Once you decide to use set_error_handler, of course you are going to
treat E_ERROR, E_NOTICE, E_USER_ERROR differently.  You want to just
halt your script for E_ERROR, but probably just tell yourself to fix
the buglet of an E_NOTICE.

You may even put them in separate logs, or perhaps even email yourself
E_ERROR, but only log E_NOTICE.

I *know* I have switch() statements on the error level in my error
handlers, and you are going to break them.

I can understand why the purist / anal-retentive camp wants
un-initiliazed varaibles as E_STRICT rather than E_NOTICE, but does it
really make that much difference?

And, honestly, there *ARE* bugs that can be introduced if somebody
makes a typo that results in using an unitialized variable.

Though the PHP auto-initialization to '' (or 0 or false or whatever is
suitable after type-juggling) works 99% of the time, imagine something
like this:

<?php
  /* lots of code */
  $foo = 42;
  /* lots of code */
  if ($foo === 42) echo "foo!";
?>

Now imagine that somebody deletes all the "lots of code" and also
accidentally deletes the initialization.

The thing you believe should be E_STRICT is, in fact, an E_NOTICE
worthy issue.

Not only CAN this happen, it HAS happened to me, and the E_NOTICE made
it patently obvious what had happened as soon as I ran my tests.

Therefore, I believe the uninitialized variables should NOT be moved
to E_STRICT.

-- 
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?



-- 
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?