Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70543
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 74.125.82.177 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAF+90c9Hxzi_JhyZkyi6Ly9zxWjgFsCBsvgzH7a8n-ce3kPKYw@mail.gmail.com>
References: <CAF+90c9Hxzi_JhyZkyi6Ly9zxWjgFsCBsvgzH7a8n-ce3kPKYw@mail.gmail.com>
Date: Mon, 9 Dec 2013 11:30:41 +0400
Message-ID: <CA+9eiLtG6PLDhh17i48qM50KjfTh=NXfsa7eO3Cu85LkPwYjJQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b5d8d451c425304ed14f927
Subject: Re: [PHP-DEV] [VOTE] Allowing use of exceptions in the engine
From: dmitry@zend.com (Dmitry Stogov)

--047d7b5d8d451c425304ed14f927
Content-Type: text/plain; charset=UTF-8

Hi Nikita,

The idea makes sense, but it really changes the fundamental design decision.
For now the patch misses more than 300 places where you'll have to find a
way to recover from a error state.
As you said, it's hardly possible in some cases (e.g. memory_limit
overflow).

Anyway, I'm not sure if the effort and risks of bugs and breaks cost the
ability of writing "dirty" code.

Thanks. Dmitry.


On Sat, Dec 7, 2013 at 4:57 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> Hi internals!
>
> I opened the vote on the "Exceptions in the engine" RFC:
>
>     https://wiki.php.net/rfc/engine_exceptions#vote
>
> The vote has three options, "Yes", "No" and "Yes, without
> E_RECOVERABLE_ERROR changes". The last option is a version of the proposal
> without BC issues.
>
> Some further notes:
>  * I will not be including something like BaseException. Introducing it for
> this purpose seems like bad design and will be very hard to get rid of in
> the future. As the proposal (without recoverable errors) does not break BC
> [1] even without it, I don't see a reason to introduce it.
>  * Some people suggest to use different subclasses of EngineException for
> different error types. I'm not against that, but I think it's okay to do
> that in a separate proposal, if someone can come up with a good selection
> of exception classes. It's much easier (and does not break BC) to add
> subclassing later, than to add suboptimal subclass types now and try to fix
> something like the SPL exception mess later.
>  * The suggested uncaught exception error message change is just a bit of
> cosmetics (and not directly related to this proposal), so I'd like to do
> that separately.
>
> And regarding the vote: If you are in favor of the proposal in general, but
> want to have it in PHP 6 rather than PHP 5.6, then vote "No" here. If it
> fails now, someone can revive this once the time for PHP 6 has come.
>
> Thanks,
> Nikita
>
> [1]: We don't have a formal definition for this, but it seems to be general
> consensus that relaxing error conditions does not constitute a backwards
> compatibility break.
>

--047d7b5d8d451c425304ed14f927--