Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70552
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.178 as permitted sender)
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 16:39:03 +0100
Message-ID: <CAEZPtU5LGXe7T_JB3-DJMcjbWzBQ=bzMY1H3K2uGii9CE7cTiQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [VOTE] Allowing use of exceptions in the engine
From: pierre.php@gmail.com (Pierre Joye)

hi,

On Sat, Dec 7, 2013 at 1: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.

I do not mind having it in 5.x or 6. but I do mind introducing
exceptions in the core without defining what we want. Baby steps are
nice but where do we stop at this stage then? Can we use exceptions in
extensions as well? Or in other parts of the engine? This is a very
good move forward but also a very critical move. We need to clarify
how we do it, where it can be done, naming or how we want them
exactly, etc.

That's why I can't vote yes with this exact proposal (and its state).

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org