Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:21187
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net,Robert Cummings <robert@interjinn.com>
Message-ID: <439D2F99.8060208@mediawave.nl>
Date: Mon, 12 Dec 2005 09:06:49 +0100
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
References: <1134339999.24194.33.camel@blobule.suds>	<1134341705.24194.42.camel@blobule.suds>  <439CBE1D.6020003@mediawave.nl> <1134347498.1723.12.camel@blobule.suds>
In-Reply-To: <1134347498.1723.12.camel@blobule.suds>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Bogus bug??
From: bart@mediawave.nl (Bart de Boer)

Robert Cummings wrote:
> 
> This sample on the bug report is actually a very whittled down version
> of where I first experienced the problem. In practice my error class is
> loaded on first error and subsequently acts as a singleton. My thoughts
> on the problem are that PHP encounters an E_STRICT exception in
> testClass.php during the parse, so it invokes the error handler, the
> error handler then loads the error class, but because the error itself
> occured during the parsing of a class PHP still thinks it's parsing the
> class and so when errorClass.php is parsed it fires the fatal error for
> class nesting. IMHO that's a parser bug since PHP should (as it normally
> does) consider an included/required class description to be outside the
> the inclusion scope.
> 
> As an FYI, the reason i use this technique is because my framework uses
> a registry type system for modular system services that are lazy loaded,
> one of which is the exception service. I guess I missed this problem in
> earlier versions of PHP5 because I filter out E_STRICT notices in the
> wrapper function that I refuse to correct in my engine for PHP4
> compatibility reasons (I currently filter 3). But it raises the issue
> that anytime a new E_STRICT type error is created that I may not have
> addressed yet, the result is a fatal error instead of an annoying
> E_STRICT :)
> 
> Cheers,
> Rob.

It looks like it happens the way you say. And I'm afraid I don't know if 
this is by PHP's design or not.

Regarding the FMY. Shouldn't error handling be something that is part of 
your framework? And not part of your plugin modules? That's the way I 
consider it with my modular apps at least. :)

Bart