Could you revive it in a new thread please? :) On Feb 13, 2015 3:25 PM, "Nikita Popov" <nikita....@gmail.com> wrote:
> 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. >
