Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70523
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.223.175 as permitted sender)
MIME-Version: 1.0
Sender: adam@adamharvey.name
In-Reply-To: <CAF+90c9Hxzi_JhyZkyi6Ly9zxWjgFsCBsvgzH7a8n-ce3kPKYw@mail.gmail.com>
References: <CAF+90c9Hxzi_JhyZkyi6Ly9zxWjgFsCBsvgzH7a8n-ce3kPKYw@mail.gmail.com>
Date: Sat, 7 Dec 2013 13:47:20 -0800
Message-ID: <CADajX4DzpfrsnL30EtcW3Luf0Yx+T=fEMLFOrJT8c6UDiOXZ6g@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] Allowing use of exceptions in the engine
From: aharvey@php.net (Adam Harvey)

On 7 December 2013 04:57, Nikita Popov <nikita.ppv@gmail.com> wrote:
> 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 proposa=
l
> without BC issues.
>
> And regarding the vote: If you are in favor of the proposal in general, b=
ut
> 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.

To be clear: I've voted -1 for exactly this reason, and this reason
alone. I don't think implementing this piecemeal (without the
E_RECOVERABLE_ERROR changes) is the right way to go =E2=80=94 I would prefe=
r
to have the whole thing as part of a 6.0 release, rather than
potentially confusing users with a partial implementation.

Notes on the notes:

>  * I will not be including something like BaseException. Introducing it f=
or
> 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 B=
C
> [1] even without it, I don't see a reason to introduce it.

+1. I think I said last time that it felt like the
mysql_real_escape_string() of exception API design. :)

>  * 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 f=
ix
> something like the SPL exception mess later.

Also +1.

Adam