Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69868
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.43 as permitted sender)
MIME-Version: 1.0
Sender: happy.melon.wiki@gmail.com
In-Reply-To: <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>
	<f038339d3be2466eb704bf6f6cf91146@EXCHLONDON2013.zoo.lan>
Date: Fri, 25 Oct 2013 16:00:15 +0100
Message-ID: <CAFKLSKCr1M+5QqGWQkjj4php8yWtLmx7a5VhGpCto_JCgxzCRw@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b33cd740c1b1204e9920213
Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine
From: happy.melon.wiki+gb@gmail.com (George Bond)

--047d7b33cd740c1b1204e9920213
Content-Type: text/plain; charset=ISO-8859-1

On 25 October 2013 15:09, Richard Bradley <Richard.Bradley@softwire.com>wrote:

> > -----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@softwire.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
> errors using "register_shutdown_function" and display an error page to the
> end user (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-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
> exception 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 listen to have a shutdown handler but now your catch would catch the
> fatal exceptions 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.
>
>
I think as far as BC breaks go, "in the event that my application has
already become unusable to the end-user, now only the sensibly-structured
catch-all codepath that we had to implement anyway is followed rather than
that other much-nastier-to-work-with codepath" is pretty uncontroversial...

--G

--047d7b33cd740c1b1204e9920213--