On Tue, Feb 17, 2015 at 11:14 AM, Bob Weinand <bobw...@hotmail.com> wrote:
> > Am 14.02.2015 um 00:25 schrieb Nikita Popov <nikita....@gmail.com>: > > > > On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov <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 > >> > >> 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... > 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 > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
