Re: Error Subclasses

Hey Anatol > Am 06.07.2015 um 12:06 schrieb Anatol Belski <anatol.php@belski.net>: > > Hi Aaron, > >> -----Original Message----- >> From: Aaron Piotrowski [mailto:aaron@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. Bob