Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69867
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: Jordi Boggiano <j.boggiano@seld.be>
CC: 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: AQHO0Yr0AGK57fWUkkCpE1NssFQnYZoFc1pA
Date: Fri, 25 Oct 2013 14:09:16 +0000
Message-ID: <f038339d3be2466eb704bf6f6cf91146@EXCHLONDON2013.zoo.lan>
References: <CAF+90c8OgW4Nonaz+HQn+gi4r+AdaEMXsTxCAhn=WO-+aQQsZQ@mail.gmail.com>
	<52699FB5.20300@garfieldtech.com>	<526A6BCC.3060502@php.net>
	<7048a577d3c04532b24585f6b043f913@EXCHLONDON2013.zoo.lan>
 <CA+GmM=wuwVzYxRzybZ_nAg=BtkNZYuOtj=VY6fAFiQ2_3jBrBA@mail.gmail.com>
In-Reply-To: <CA+GmM=wuwVzYxRzybZ_nAg=BtkNZYuOtj=VY6fAFiQ2_3jBrBA@mail.gmail.com>
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: Jordi Boggiano [mailto:j.boggiano@seld.be]
> Sent: 25 October 2013 15:03
> To: Richard Bradley
> Cc: Joe Watkins; internals@lists.php.net; Larry Garfield
> Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine
>
> On Fri, Oct 25, 2013 at 3:55 PM, Richard Bradley <Richard.Bradley@softwir=
e.com> wrote:
> >> How could anything be reliant on the behaviour of a fatal error in any=
 meaningful way ??
> >>
> >> Cheers
> >> Joe
> >
> > In plenty of ways: for example currently frameworks can "catch" fatal e=
rrors using "register_shutdown_function" and display an error page to the e=
nd user (say if there is an attempt to call a method on a null object due t=
o an unanticipated runtime error).
> >
> > Current frameworks might be broken if the way fatal errors work is chan=
ged. That would be a BC break.
> >
> > See e.g.
> > http://stackoverflow.com/questions/16284235/zend-framework-error-page-
> > for-php-fatal-errors/16284260#16284260
> >
> > (This is not a vote for or against this proposal; I'm just answering
> > the immediate parent here.)
>
> Wouldn't this sort of use case be covered by the fact that an uncaught ex=
ception would still result in a fatal error? The only case it'd "break" is =
if you have a try/catch around your entire application, before you had to l=
isten to have a shutdown handler but now your catch would catch the fatal e=
xceptions before they bring everything down.

You might still end up in the register_shutdown_function yes, but the error=
 code would have changed (from error_get_last())
i.e. people may well be relying on the exact behaviour of fatal errors.

It would be great to fix the somewhat messy state of exceptions & errors in=
 PHP, but we shouldn't pretend that we can do so without BC breaks.





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