Hi Bob, > -----Original Message----- > From: Bob Weinand [mailto:bobw...@hotmail.com] > Sent: Monday, July 6, 2015 2:59 PM > To: Anatol Belski > Cc: Aaron Piotrowski; internals@lists.php.net > Subject: Re: [PHP-DEV] Error Subclasses > > Hey Anatol > > > Am 06.07.2015 um 12:06 schrieb Anatol Belski <anatol....@belski.net>: > > > > Hi Aaron, > > > >> -----Original Message----- > >> From: Aaron Piotrowski [mailto:aa...@icicle.io] > >> Sent: Monday, July 6, 2015 8:16 AM > >> To: internals@lists.php.net > >> Subject: [PHP-DEV] Error Subclasses > >> > >> 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. > >> > >> I was hoping this could be merged before beta 1, though I’m not sure > >> if the time table is too tight. > >> > > Thanks for the ping. While I find the idea about more specific exceptions > correct, I would not recommend merging it in beta1. Reason - we have no big > time now to verify the patch completeness, to discuss the exception names and > areas where it's applicable. > > > > IMHO if it goes in, it has to be complete and well verified, maybe also > > voted > (regarding namings). As the area is very public and if we find any issues > later and > have to rename/rework the exception names, etc. - it would be bad. So 7.1 > might be a better place to target. Technically it would be anyway worky as > those > specialized extension classes will have the same parent. > > > > Regards > > > > Anatol > > I like what Aaron did here. > > I really think that should target 7.0. It's actually not breaking anything > (really just > changing the exception names). > And I really think we should have a proper Error hierarchy at the release of > PHP > 7.0. Considering it especially one of *the* features of 7.0. > > But I think, at end of beta 2 or so, we really should do a final review of > all the > Errors in order to ensure everything is aptly named and used. > Thanks for the feedback. That's what I said as well - the idea is correct. Unfortunately it is too late. Just to remind - Trowable was too late as well by the time no more new RFCs was allowed. But as it was important and still acceptable in the alpha phase, so there was an exception for the exception RFC. This gives a good base to for further improvements.
Now with actual subject - it's has nothing to do with the Trowable directly as it's in. However I don't think it's to decide by me, you or anyone else alone, whether the names fit good. Also in such a short period it's hard to check whether alle the needed places are touched and everything is ok. These are two main concerns preventing this to go in, IMHO. And we cannot target beta2 because it's a feature freeze already tomorrow when beta1 is tagged. One can argue, sure ... but some when there should be a clean cut. Then we should be working on fixing bugs and stabilizing the codebase. This PR is not a bug fix. Thus, 7.1 - this well thought and good tested feature would be welcome there. Starting with the time we've branched the 7.0 dev branch (middle September), the door is popen for any good features and RFCs. Now, having what we have - Error where it is, nothing is lost, as AnotherError extends Error. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
