Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69865
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain softwire.com designates 195.130.217.221 as permitted sender)
To: Joe Watkins <krakjoe@php.net>, "internals@lists.php.net"
	<internals@lists.php.net>, Larry Garfield <larry@garfieldtech.com>
Thread-Topic: [PHP-DEV] [RFC] Exceptions in the engine
Thread-Index: AQHO0OXpAGK57fWUkkCpE1NssFQnYZoEXvKAgADzTACAAB5DcA==
Date: Fri, 25 Oct 2013 13:55:50 +0000
Message-ID: <7048a577d3c04532b24585f6b043f913@EXCHLONDON2013.zoo.lan>
References: <CAF+90c8OgW4Nonaz+HQn+gi4r+AdaEMXsTxCAhn=WO-+aQQsZQ@mail.gmail.com>
 <52699FB5.20300@garfieldtech.com> <526A6BCC.3060502@php.net>
In-Reply-To: <526A6BCC.3060502@php.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
MIME-Version: 1.0
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PHP-DEV] [RFC] Exceptions in the engine
From: Richard.Bradley@softwire.com (Richard Bradley)

> -----Original Message-----
> From: Joe Watkins [mailto:krakjoe@php.net]
> Sent: 25 October 2013 14:02
> To: internals@lists.php.net; Larry Garfield
> Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine
>
> On 10/24/2013 11:31 PM, Larry Garfield wrote:
> > On 10/24/13 12:41 PM, Nikita Popov wrote:
> >> Hi internals!
> >>
> >> I'd like to propose an RFC, which allows the use of exceptions within
> >> the engine and also allows changing existing fatal errors to exception=
s:
> >>
> >>      https://wiki.php.net/rfc/engine_exceptions
> >>
> >> This topic has been cropping up in the discussions for several of the
> >> recent RFCs and I think the time has come to consider moving away
> >> from fatal errors.
> >>
> >> Thoughts?
> >>
> >> Thanks,
> >> Nikita
> >
> > As a PHP user-space developer I love this idea.  However, I share the
> > concern of others here that it could result in BC unpleasantness, even
> > if limited to the E_FATAL and E_RECOVERABLE_FATAL use cases.  I don't
> > know off hand how various versions of Drupal would handle this.
> >
> > --Larry Garfield
>
> How could anything be reliant on the behaviour of a fatal error in any me=
aningful way ??
>
> Cheers
> Joe

In plenty of ways: for example currently frameworks can "catch" fatal error=
s using "register_shutdown_function" and display an error page to the end u=
ser (say if there is an attempt to call a method on a null object due to an=
 unanticipated runtime error).

Current frameworks might be broken if the way fatal errors work is changed.=
 That would be a BC break.

See e.g. http://stackoverflow.com/questions/16284235/zend-framework-error-p=
age-for-php-fatal-errors/16284260#16284260

(This is not a vote for or against this proposal; I'm just answering the im=
mediate parent here.)

Best,


Rich





Richard Bradley
Tel : 020 7485 7500 ext 3230 | Fax : 020 7485 7575

softwire
Sunday Times Best Small Companies - UK top 20 three years running
Web : www.softwire.com | Addr : 325 Highgate Studios, 53-79 Highgate Road, =
London NW5 1TL
Softwire Technology Limited. Registered in England no. 3824658. Registered =
Office : 13 Station Road, London N3 2SB