Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86531
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain icicle.io designates 199.38.81.6 as permitted sender)
Content-Type: multipart/alternative; boundary="Apple-Mail=_1818E0CD-5471-4B1B-8BDA-9DB99BA3C6A4"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
In-Reply-To: <CAFMT4NppuzY1dhPVcVhFFB-0373AkuB4-dh-mynY0p6R9T76tw@mail.gmail.com>
Date: Tue, 9 Jun 2015 13:54:36 -0500
Cc: internals@lists.php.net
Message-ID: <3F8B83EF-DB7C-4CA5-B1DF-9C490A95A5F0@icicle.io>
References: <971AB39D-1E20-43E8-9CF1-A7F67E3C14C3@icicle.io> <CAGa2bXb8CaJsJorx0HTzSgEeAGXJN7DoW5vi=m+wFiUXNw+tng@mail.gmail.com> <556363D3.1040902@gmail.com> <12C3389A-AFF5-42CA-8190-E4227309DAED@icicle.io> <CAFMT4NppuzY1dhPVcVhFFB-0373AkuB4-dh-mynY0p6R9T76tw@mail.gmail.com>
To: Levi Morrison <levim@php.net>
Subject: Re: [PHP-DEV] [RFC] Throwable Interface
From: aaron@icicle.io (Aaron Piotrowski)

--Apple-Mail=_1818E0CD-5471-4B1B-8BDA-9DB99BA3C6A4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Jun 9, 2015, at 1:13 PM, Levi Morrison <levim@php.net> wrote:
>=20
> My only objections have already been raised, but I'll reiterate them =
briefly:
>=20
>  1. Having both Error and Exception makes little sense, especially
> since we have historically used error to refer to an error that wasn't
> an exception (something that triggered the error handler).
>  2. The name "Error" is going to have a fairly high collision rate
> with user code.
>  3. I think they should all use Exception as the root instead having
> a new root with multiple children (and yes, I am aware of the impact
> of this, and it has already been discussed on this list).
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php =
<http://www.php.net/unsub.php>
I outlined the reasons for the Error name choice in the RFC. While it =
may cause some confusion, I feel it is a
better choice than obfuscating the different exception branches with =
similar class names. Having a class
named TypeException that does not extend Exception is unintuitive. I =
think users will be confused by
catch (Exception $e) not catching TypeException. Using a different =
suffix makes it clearer that
catch (Error $e) is necessary to catch TypeError.

Error will collide with some user code, but changing the name of a class =
to make code compatible with PHP 7
is a relatively easy change to make, largely accomplished with a =
find-and-replace. Hopefully most user code is
using namespaces and collisions will be avoided.

Suggestions are certainly welcome for a different name, but honestly I =
think Error makes a lot of sense.
Non-fatal errors in PHP will trigger notices and warnings, while fatal =
errors can be thrown. Users likely will use
the term =E2=80=98Uncaught Error=E2=80=99 when searching, minimizing the =
overlap with information about non-fatal errors.

Perhaps it would be best if the vote was separated:

1) Replace BaseException with Throwable interface. Hierarchy otherwise =
remains as-is, with EngineException
implementing Throwable, TypeException extending EngineException, and =
ParseException implementing
Throwable.

2) If (1) is accepted, also change EngineException to Error, =
TypeException to TypeError, and ParseException
with ParseError, with TypeError and ParseError extending Error.

Regards,
Aaron Piotrowski=

--Apple-Mail=_1818E0CD-5471-4B1B-8BDA-9DB99BA3C6A4--