Re: [RFC] Exceptions in the engine

> Am 14.02.2015 um 00:25 schrieb Nikita Popov <nikita.ppv@gmail.com>: > > On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov <nikita.ppv@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 >> >> 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 >> > > 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... Thanks, Bob