Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56627
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
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>
Date: Fri, 25 Nov 2011 11:15:28 +0100
Message-ID: <CAH-PCH7-jUoFMi-icy7947shB1g72NiF8LTr885jR2mHJM_Otg@mail.gmail.com>
To: Sebastian Krebs <krebs.seb@googlemail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=001636499237ac8ecc04b28c6e59
Subject: Re: [PHP-DEV] Re: [RFC] Autoloader Error Handling
From: tyra3l@gmail.com (Ferenc Kovacs)

--001636499237ac8ecc04b28c6e59
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.
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
<krebs.seb@googlemail.com>wrote:

> Hi,
>
> Just to throw my 2 cent in: Im with Micheal. An application, that tries t=
o
> 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 betwee=
n
> 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 clas=
s
> > couldn't be loaded. I do this by adding a try/catch block around my cod=
e.
> >
> > 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
> >
> >
>



--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001636499237ac8ecc04b28c6e59--