Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56641
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.26 cause and error)
Message-ID: <4ED055E9.2090809@garfieldtech.com>
Date: Fri, 25 Nov 2011 20:58:49 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: internals@lists.php.net
References: <4ECEC513.9040706@mohiva.com> <EA.C2.16974.AC24FCE4@pb1.pair.com> <06acba1a1c53ac9527beb807787c92aa@mohiva.com> <CALtuQzDpNRiveBbYj9B9ekYVnMBGHaSU4o=B3bEEdOKAsoqwGw@mail.gmail.com> <CAH-PCH7-jUoFMi-icy7947shB1g72NiF8LTr885jR2mHJM_Otg@mail.gmail.com> <CALtuQzA7NBkvZm6R-=4Cc5HgKBNK6CbA7U7NjrB1BR9N=e-f4A@mail.gmail.com>
In-Reply-To: <CALtuQzA7NBkvZm6R-=4Cc5HgKBNK6CbA7U7NjrB1BR9N=e-f4A@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC] Autoloader Error Handling
From: larry@garfieldtech.com (Larry Garfield)

On 11/25/2011 04:21 AM, Sebastian Krebs wrote:
> 2011/11/25 Ferenc Kovacs<tyra3l@gmail.com>
>
>> The problem with fatal, that you have no way (by the standard means, but
>> you can somehow manage it through the usage of output buffers or
>> register_shutdown_function, but thats ugly, and can change in the future)
>> to intercept and gracefully terminate your application, which is an often
>> needed feature.
>> AFAIK E_FATAL should be only used where the engine is left in an unstable
>> state, which isn't really true here.
>>
>
> Trying to interact with a non-existing class is not an unstable state?
>
> there are two situations:
>
> 1. The application is broken, thus the FATAL is appropriate
> 2. The application tries to work with dynamic class names. If it doesn't
> use class_exists() before, its broken and FATAL is appropriate
>
>
> So I think that E_RECOVERABLE_ERROR would be more appropriate here, and in

There's a third possibility.

3) The application uses a mapped or indexed autoloader and the map is 
out of date.  Rebuilding the map would resolve the error.

So I could see a use for a recovery there; if new NonExistentClass 
fails, try to rebuild the index and try again before fataling out entirely.

Whether that's too much of an edge case or not, I don't know, but it is 
a legitimate use case.  (Drupal 7 has an indexed autoloader, and we've 
run into the stale index problem many times.  We're trying to migrate 
most code to PSR-0 for Drupal 8, but even that could use an index for 
caching/performance reasons.)

--Larry Garfield