Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77846
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <543320AB.4070606@sugarcrm.com>
References: <CAF+90c-7w1fLqmffYvPRhmtt8rzESEpSmW8vfMD-YfLt1mG_8w@mail.gmail.com>
	<543320AB.4070606@sugarcrm.com>
Date: Fri, 10 Oct 2014 13:46:47 +0200
Message-ID: <CAF+90c9+0+3TLKNdF=dnZ+OJb1UTNfeQ=ohMBrtJF=ZDXbZ23A@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0444814b97da9b0505101a12
Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine
From: nikita.ppv@gmail.com (Nikita Popov)

--f46d0444814b97da9b0505101a12
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 7, 2014 at 1:07 AM, Stas Malyshev <smalyshev@sugarcrm.com>
wrote:

> Hi!
>
> > 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.
>
> I like this. Fatal errors and warnings were for a long time in different
> leagues, and the need to handle them better produced E_RECOVERABLE_ERROR
> which is a weird creature - like exception but not quite. I think PHP 7
> is a good time to move to exceptions for real errors (as opposed to
> informational messages like E_WARNING).
>
> The only issue I think we need to discuss is catch(Exception $e). Now it
> would catch much more than before, if we do no changes. Should we allow
> it or should be have hierarchy that separates user exceptions and engine
> exceptions, and have catch(Exception) catch only the former.
>

There is precedent in other languages for having exceptions that are not
usually caught. Java has a Throwable interface, which is implemented by
Exceptions and Errors, where the latter are usually not supposed to be
caught. Python has a BaseException, which is extended by Exception and
SystemExit, GeneratorExit and KeyboardInterrupt, where the latter three are
not usually supposed to be caught.

I think that the decision whether or not we wish to introduce something
like this mainly depends on how we intend these EngineExceptions to be
used. If they are only supposed to be caught by top-level code to enable
graceful error handling (in particular for long running code) then it
probably makes sense to keep them outside the main exception hierarchy. If
on the other hand it's considered okay to catch them during normal program
execution, they should be normal exceptions.


> However, I see in the RFC it does not remove all the errors. I think we
> need to strive for having all the non-core errors except for out of
> memory and timeout be converted. Are there ones that are problematic to
> convert or it is just the question of time/effort?
>

There are a number of E_ERRORs that we cannot feasibly convert to
exceptions. I've analyzed this for the previous discussion and likely the
numbers are still about right: http://markmail.org/message/gfdczr6zpgzynid4
So a conservative estimate is that we can turn 85% of the E_ERROR
occurrences into exceptions. (This doesn't tell us anything about the
percentage of actually thrown errors though.)

And yes, it's also a question of time/effort. The hard part usually isn't
converting to exceptions, but updating all the tests that fail because of
it. I'd like to have good exception coverage by the time PHP 7 gets
released, but would prefer to do the porting incrementally (these huge
patches get stale very fast).

Nikita

--f46d0444814b97da9b0505101a12--