> Am 17.02.2015 um 11:21 schrieb Benjamin Eberlei <kont...@beberlei.de>: > On Tue, Feb 17, 2015 at 11:14 AM, Bob Weinand <bobw...@hotmail.com > <mailto:bobw...@hotmail.com>> wrote: > > Am 14.02.2015 um 00:25 schrieb Nikita Popov <nikita....@gmail.com > > <mailto:nikita....@gmail.com>>: > > > > On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov <nikita....@gmail.com > > <mailto:nikita....@gmail.com>> wrote: > > > >> Hi internals! > >> > >> During the PHP 5.6 development cycle I have proposed an RFC [1] that > >> suggested the use of exceptions instead of fatal errors in the engine. At > >> the time the proposal was declined, because the change was judged too > >> intrusive for a minor version. > >> > >> As such I'm re-proposing this RFC for inclusion in PHP 7: > >> > >> https://wiki.php.net/rfc/engine_exceptions_for_php7 > >> <https://wiki.php.net/rfc/engine_exceptions_for_php7> > >> > >> The RFC text is essentially the same as previously, with the primary > >> difference being that parse errors are now converted to exceptions as well. > >> This was previously not possible due to limitations in the compiler design. > >> > >> Thanks, > >> Nikita > >> > >> [1]: https://wiki.php.net/rfc/engine_exceptions > >> <https://wiki.php.net/rfc/engine_exceptions> > >> > > > > Feature freeze is not so far away now, so I'd like to bring this RFC up > > again and proceed to voting shortly. There are two primary open questions: > > > > * Subclassing: Should there be more specific subclasses of EngineException > > for particular errors? > > * Superclassing: Should EngineException inherit from Exception (and as > > such be subject to catch(Exception)) or should we introduce some kind of > > special super-class that is not caught by default (like > > Catchable/Throwable)? > > > > I don't think we can implement a high-quality subclassing scheme in a > > timeframe for PHP 7, as such I would suggest to postpone this (if we > > actually want to do it) to a later point in time. We can introduce > > subclasses without BC issues in a minor version. > > > > The question of whether EngineException should inherit from Exception is > > something we do have to consider now. Personally I prefer not introducing > > any special exception types that aren't caught by default. I think that > > would only make sense for errors that could occur literally everywhere > > (like memory limit or timeout), but these are not handled by this RFC for > > technical reasons. If someone has a strong opinion on this, I might make it > > a voting option. > > > > Commentary on these, and also any other relevant points is very welcome! > > > > Thanks, > > Nikita > > > > PS: The patch attached to the RFC is very outdated. I plan to only update > > it to current master once the RFC passes (if it does), as I already had to > > practically rewrite it a few times. > > Hey, > > For subclassing I totally agree that we should postpone this (if we want this > at all). > > I think EngineException should inherit from Exception. You usually only catch > Exception in catch-all handlers to display, log etc. the backtraces. In all > these cases, you're very likely to want to catch the EngineException too, > without a second catch block where the catch body is duplicated. > I can't really think of a catch-all block where you'd explicitly don't want > to handle EngineException. And if it'd really be the case, you still can do > an instanceof check and rethrow if needed... > > I think that would be a huge BC break. I see a lot of code just catching > \Exception at various customers and opensource projects. EngineException > should not be a child of Exception. > > Thanks, > Bob
No, it isn't a BC break. It would only affect broken things, which generate fatals as of now. Working applications are not affected and that way it does not break BC. So, I don't see any harm here in superclassing EngineException. Bob
