Re: [RFC] Exceptions in the engine

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