2015-07-07 2:22 GMT+02:00 Pierre Joye <pierre....@gmail.com>: > hi Aaron, > > On Mon, Jul 6, 2015 at 1:15 PM, Aaron Piotrowski <aa...@icicle.io> wrote: > > Hello everyone! > > > > I recently pushed changes that eliminated E_EXCEPTION and allows an > exception type to be provided for what were fatals in PHP, while still > falling back to an E_ERROR if necessary. > > > > Since more specific Error classes can be thrown, I'd like to propose the > following additions to the Error tree of exceptions: AccessError and > IdentifierError. > > > > AccessError - Thrown when trying attempting to call a public, private, > or abstract method, when statically calling a non-static method, or trying > to use self::, parent::, or static:: outside of a class. > > IdentifierError - Thrown when referencing an undefined function, method, > class, constant, etc. > > > > I’ve created a patch that implements the exceptions above as well as > updating all the related tests: > https://github.com/trowski/php-src/tree/error-subclasses < > https://github.com/trowski/php-src/tree/error-subclasses> > > > > This patch also broadens the usage of TypeError to include conditions > such as calling a method on a scalar, passing a value that does not specify > a callback when one is expected, and various other conditions based on an > incorrect type that otherwise are throwing plain Error objects. > > > > This patch introduces no functional changes, only more specific types of > Errors are thrown from conditions that were already throwing Error objects. > > Very good job! Thanks. > > > I was hoping this could be merged before beta 1, though I’m not sure if > the time table is too tight. > > > In any case you may like to start a RFC already, no matter if which > versions it targets. > > About 7.0 in general, naming and conventions are something I like to > see solved in 7.0. I do not think it affects stability in any way and > should not delay the final release date. One argument in favor of such > exceptions (if approved by RFC votes) is that dealing with such > changes or additions for the core languages in minor versions is > somehow more painful for our users. > > In any case, please go for a RFC and see what gets out of it :) > > Cheers, > -- > Pierre > > @pierrejoye | http://www.libgd.org > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > I'm with Anatol here. It's no BC break if we only introduce subtypes instead of the parent type, but it would be a BC break afterwards if the names we choose now do not then. It feels pretty rushed to get it in before beta1 (which is the final feature freeze).
As errors shouldn't be caught except for logging, there's also little benefit in rushing in subtypes them now. The only benefit that I can see is the exception name as a short and concise error description. It's nothing like Throwable, which needed that exception, because a later introduction would have been a BC break. Regards, Niklas
