Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:56632 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 84709 invoked from network); 25 Nov 2011 12:11:44 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Nov 2011 12:11:44 -0000 Authentication-Results: pb1.pair.com smtp.mail=christian.kaps@mohiva.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=christian.kaps@mohiva.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain mohiva.com from 80.67.29.23 cause and error) X-PHP-List-Original-Sender: christian.kaps@mohiva.com X-Host-Fingerprint: 80.67.29.23 smtprelay01.ispgateway.de Linux 2.6 Received: from [80.67.29.23] ([80.67.29.23:44298] helo=smtprelay01.ispgateway.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 26/31-12107-DF58FCE4 for ; Fri, 25 Nov 2011 07:11:41 -0500 Received: from [80.67.16.111] (helo=webmail.df.eu) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1RTud0-0006X4-4s for internals@lists.php.net; Fri, 25 Nov 2011 13:11:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 25 Nov 2011 13:11:38 +0100 To: In-Reply-To: References: <4ECEC513.9040706@mohiva.com> <06acba1a1c53ac9527beb807787c92aa@mohiva.com> Message-ID: <320513b71f351afaec29a6b775a56b1a@mohiva.com> X-Sender: christian.kaps@mohiva.com User-Agent: Roundcube Webmail/0.6 X-Df-Sender: Y2hyaXN0aWFuLmthcHNAbW9oaXZhLmNvbQ== Subject: Re: [PHP-DEV] Re: [RFC] Autoloader Error Handling From: christian.kaps@mohiva.com (Christian Kaps) Can we stay on topic please. At this time I count a vast number of mails, but never has talked about the RFC. Fact is that these three cases, how a autoloader terminates, exists in PHP. If all these cases are useful is an other topic. Can we all agree on this? Am 25.11.2011 11:21, schrieb Sebastian Krebs: > 2011/11/25 Ferenc Kovacs > >> 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 >> general we use E_ERROR many places where E_RECOVERABLE_ERROR would >> be more >> suitable, but thats another topic. >> >> For clarification: I'm talking about the E_FATAL which currently >> will be >> called if none of the registered autoloaders were able to load the >> requested class. >> >> On Fri, Nov 25, 2011 at 9:56 AM, Sebastian Krebs >> > > wrote: >> >>> 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). >>> 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 >>> >>> > 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 >>> > >>> > >>> >> >> >> >> -- >> Ferenc Kovács >> @Tyr43l - http://tyrael.hu >>