Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69849
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.223.178 as permitted sender)
MIME-Version: 1.0
Sender: adam@adamharvey.name
In-Reply-To: <CAF+90c8OgW4Nonaz+HQn+gi4r+AdaEMXsTxCAhn=WO-+aQQsZQ@mail.gmail.com>
References: <CAF+90c8OgW4Nonaz+HQn+gi4r+AdaEMXsTxCAhn=WO-+aQQsZQ@mail.gmail.com>
Date: Thu, 24 Oct 2013 11:01:06 -0700
Message-ID: <CADajX4AWmpv_mVVGvsczmKoWyqdNOd+M51cNxmuSUfSXVqrQ_w@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] [RFC] Exceptions in the engine
From: aharvey@php.net (Adam Harvey)

On 24 October 2013 10:41, Nikita Popov <nikita.ppv@gmail.com> wrote:
> I'd like to propose an RFC, which allows the use of exceptions within the
> engine and also allows changing existing fatal errors to exceptions:
>
>     https://wiki.php.net/rfc/engine_exceptions
>
> This topic has been cropping up in the discussions for several of the
> recent RFCs and I think the time has come to consider moving away from
> fatal errors.
>
> Thoughts?

I love the idea =E2=80=94 unified error and exception handling would be a h=
uge
win both for simplifying code bases and teaching new developers =E2=80=94 b=
ut
I don't see any possible way we could do this in a 5.x release. The BC
issues are just too great, and too many people rely heavily on the
set_error_handler() behaviour that we have today.

A couple of specific points that jumped at out me on my first skim:

1. I know Python has BaseException, but it feels a little like the
exception version of functions with the name "real" in them. :) If
this was $next_major material, then we could probably look at keeping
Exception as the top level and inserting a UserException under it that
userland exceptions derive from. (Or just not do it at all.)

2. Again, if this is $next_major material, I wouldn't selectively
convert errors to exceptions as the "policy changes" section suggests
=E2=80=94 let's do them all and be done with it, and the only things that
would still be errors are genuinely uncatchable things that already
can't be handled by set_error_handler().

There's probably a broader discussion here around whether we should be
starting to think about a new major release and what that would look
like, but that's definitely not for this thread!

Adam