Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70533
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <bf72a3b3f08321543979442e053092fb@mail.gmail.com>
References: <CAF+90c9Hxzi_JhyZkyi6Ly9zxWjgFsCBsvgzH7a8n-ce3kPKYw@mail.gmail.com>
	<bf72a3b3f08321543979442e053092fb@mail.gmail.com>
Date: Sun, 8 Dec 2013 15:18:20 +0100
Message-ID: <CAF+90c9jDnOrUqOGsbuqRFDWHX_xZsegVsrgN_5XOXYU8U14rg@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0149ca1029f4be04ed068d9c
Subject: Re: [PHP-DEV] [VOTE] Allowing use of exceptions in the engine
From: nikita.ppv@gmail.com (Nikita Popov)

--089e0149ca1029f4be04ed068d9c
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Dec 8, 2013 at 2:55 PM, Zeev Suraski <zeev@zend.com> wrote:

> Nikita,
>
> Apologies for not having followed the discussion a few weeks ago but I
> think this proposal can't be accepted as it is even if everyone likes it.
> It breaks a very basic design concept in the way both the engine code as
> well as extension code is written - execution will never resume beyond an
> E_ERROR.
>
> Allowing execution to resume (through the use of exceptions) opens a huge
> can of worms, and sets expectations we can't meet.  In fact, the main
> difference between E_ERROR and E_WARNING is the recoverability, so this is
> not some small detail we can fix - we simply can't assume execution can
> continue after an E_ERROR is triggered, because E_ERROR in its very
> essence implies no-resumed-execution.  That's also the reason error
> handlers (that existed before exceptions did) don't handle E_ERROR.
>
> I don't think a vote makes a lot of sense here, since it's asking people
> whether they're in favor of the concept of being able to recover from any
> kind of error.  That's the wrong question (to which, by the way, I'd vote
> 'yes').  The real question is whether people are OK that the engine will
> start randomly crashing through the use of standard PHP code, which is
> pretty much out of the question.
>
> If there are E_ERROR's which you think are erroneously tagged as E_ERROR's
> and should in fact be E_RECOVERABLE_ERROR, we should change them, rather
> than assuming that E_ERRORs can be tagged as recoverable wholesale...
>

Hi Zeev!

I think this is a misunderstanding... I'm not suggesting to simply let the
engine continue after an E_ERROR - as you pointed out, that would likely
just crash it a few lines further down.

This RFC is mainly a policy RFC: The goal is to allow the use of exceptions
in the engine and to allow changing existing fatal errors to exceptions.
The change from fatal errors to exceptions needs to happen manually, by
adjusting the surrounding code to support continued execution (usually that
means freeing resources + returning). A lot of fatal errors are easy to
change, others are very hard or impossible. Changing fatal errors to
exceptions rather than recoverable errors is both more useful to the end
user and technically easier (as recoverable errors need to continue
execution in the same codepath, which is often a lot harder to implement
and find appropriate semantics for), which is why I'm suggesting this
particular course of action.

So, basically what I'm suggest is what you say in the last paragraph, just
going directly to exceptions rather than converting to E_RECOVERABLE_ERROR
:)

Hope this is a bit clearer.

Nikita

--089e0149ca1029f4be04ed068d9c--