> On Jun 9, 2015, at 1:13 PM, Levi Morrison <le...@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
