Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83197
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c8NAROuCDgRajF4AN2oTc4fzmxTjtVC_OAQH=ZFm5N9Uw@mail.gmail.com>
References: <CAF+90c-7w1fLqmffYvPRhmtt8rzESEpSmW8vfMD-YfLt1mG_8w@mail.gmail.com>
	<CAF+90c8NAROuCDgRajF4AN2oTc4fzmxTjtVC_OAQH=ZFm5N9Uw@mail.gmail.com>
Date: Thu, 19 Feb 2015 19:13:39 +0400
Message-ID: <CA+9eiLtgZq4HrXTaY_=traLAi7qR76F=HNAx=QCw7woNQOZvYg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113399e681fc0f050f726106
Subject: Re: [PHP-DEV] Re: [RFC] Exceptions in the engine
From: dmitry@zend.com (Dmitry Stogov)

--001a113399e681fc0f050f726106
Content-Type: text/plain; charset=UTF-8

Hi Nikita,

I refactored your implementation: https://github.com/php/php-src/pull/1095

I introduced a class hierarchy to minimize effect on existing code.
cacth (Exception $e) won't catch new types of exceptions.

BaseException (abstarct)
 +- EngineException
 +- ParaseException
 +- Exception
     +-ErrorException
     +- all other exceptions

In case of uncaught Parse and EngineEexception PHP writes the compatible
error message.
I made it mainly to keep thousand PHPT tests unchanged.
If you like we may introduce an ini option that will lead to emitting of
"Uncaught Exception ... " with backtrace instead.

The internal API was changed a bit. e.g. EngineException are thrown from
zend_error(), if the error_code has E_EXCEPTION bit set.
So to change some error into exception now we should change
zend_error(E_ERROR,...) into zend_error(E_EXCEPTION|E_ERROR. ...)

All tests are passed.
I'm not sure about sapi/cli/tests/bug43177.phpt, because it started to fail
also in master.

We may need to replace E_RECOVERABLE_ERROR with E_ERROR and fix
corresponding tests.
Despite of this, I think the patch is good enough to be merged into master.

We may decide to convert more fatal errors later, but it shouldn't prevent
from putting RFC into vote.

Thoughts?

Thanks. Dmitry.


On Sat, Feb 14, 2015 at 2:25 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> 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.
>

--001a113399e681fc0f050f726106--