Re: [RFC] Throwable Interface
| From: | Aaron Piotrowski | Date: | Tue, 09 Jun 2015 18:54:36 +0000 |
| Subject: | Re: [RFC] Throwable Interface | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-86531@lists.php.net to get a copy of this message | ||
> On Jun 9, 2015, at 1:13 PM, Levi Morrison <levim@php.net> wrote:
>
> My only objections have already been raised, but I'll reiterate them briefly:
>
> 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).
>
> --
> 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 ‘Uncaught Error’ 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