Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56621
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mohiva.com from 80.67.18.16 cause and error)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Fri, 25 Nov 2011 10:37:06 +0100
To: <internals@lists.php.net>
In-Reply-To: <CALtuQzDpNRiveBbYj9B9ekYVnMBGHaSU4o=B3bEEdOKAsoqwGw@mail.gmail.com>
References: <4ECEC513.9040706@mohiva.com>
 <EA.C2.16974.AC24FCE4@pb1.pair.com>
 <06acba1a1c53ac9527beb807787c92aa@mohiva.com>
 <CALtuQzDpNRiveBbYj9B9ekYVnMBGHaSU4o=B3bEEdOKAsoqwGw@mail.gmail.com>
Message-ID: <da07c792c1bb65d377313f712875eaad@mohiva.com>
User-Agent: Roundcube Webmail/0.6
Subject: Re: [PHP-DEV] Re: [RFC] Autoloader Error Handling
From: christian.kaps@mohiva.com (Christian Kaps)

Hi,

comments inline.


Am 25.11.2011 09:56, schrieb Sebastian Krebs:
> Hi,
>
> Just to throw my 2 cent in: Im with Micheal. An application, that 
> tries to
> access a class, that doesn't exists, is broken and a FATAL is valid. 
> This
> application doesn't need try-catch, but a bugfix (and if it is 
> already
> released: A better testing management).

How you will be informed about that the application breaks? OK, you can 
do this with a good log management tool or a log server. But the easiest 
way is to write a mail. An other problem is that the user sees mostly a 
white page on a fatal error. An other advantage of the exception 
approach is that you can collect data from session, from request or from 
server and send this with the mail. With a fatal error this isn't 
possible.

Your objection with the test management is valid. But I'd rather be 
insured against all accidents.

The problem is that the engine allows to throw exceptions. So either we 
need a solution to handle all cases or it shouldn't possible to throw 
exceptions. The particular approaches shouldn't be the problems here.

> On the other side an application, that makes use of dynamic class 
> names
> should make use of class_exists() in any case. An exception after 
> calling
> class_exists() is just bad, but the classloader cannot distinguish 
> between
> the reasons, why it is called.
>
> 2011/11/25 Christian Kaps <christian.kaps@mohiva.com>
>
>> Am 25.11.2011 08:24, schrieb Michael Wallner:
>>
>>  On Thu, 24 Nov 2011 23:28:35 +0100, Christian Kaps wrote:
>>>
>>>
>>>> 
>>>> https://wiki.php.net/rfc/**autoloader_error_handling<https://wiki.php.net/rfc/autoloader_error_handling>
>>>>
>>>>
>>> Throwing an exception or fatal error in an autoloader
>>> absolutely does not make any sense in my eyes.
>>> Projects doing this should step back and think a
>>> minute about what they dare.
>>>
>>> Mike
>>>
>>
>> Hi,
>>
>> how would you bring your application in a consistent state after a 
>> class
>> couldn't be loaded. I do this by adding a try/catch block around my 
>> code.
>>
>> try {
>>    new Application();
>> } catch (Exception) {
>>    // collect data
>>    // send mail
>>    // redirect to maintenance page
>> }
>>
>> An other question is, if the autoloader work silent and I write:
>>
>> new NotExistingClass();
>>
>> I think in this case the engine will also trigger a fatal error. So 
>> in my
>> eyes it is regardless of whether it trigger a fatal error in the 
>> autoloader
>> or the autoloader works silent. Both cases ends in a fatal error. Or 
>> am i
>> wrong here?
>>
>> Christian
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>