Re: [PEPr] -1 for RFC::Error Handling Guidelines for PHP5

Sergio Carvalho wrote:

Greg Beaver wrote:

In fact, it does not even go into enough detail on how to name exceptions. With the current proposal, these are all allowed: - MyPackage_ExceptionSomeCondition - MyPackage_Exception_SomeCondition - MyPackage_Exception_Some_Condition

Do we have to define these? Won't we be overimposing on the developer? Remember that class naming is already covered by the current CG, so there's not much freedom left.

Since exceptions are class instances they *should* follow PEAR's CS for class naming. However due to potentially very long names, I suggest we *may* use something in line with: MyPackage_E_SomeCondition and MyPackage_E_SomeCondition_WithHierarchy and MyPackage_E_SomeCondition_WithHierachy_WithDeeperHierarchy... IMHO the "E" clearly stands for "Exception/Error". Some people may argue that it sounds too much like an error code but 8 characters less to type for each and every catch() block will save a lot of time... Let's also remember that these class names will be in throw() and catch() statements, making clear they *are* exceptions. For performance issue, exception class definitions *may* be declared into one "MyPackage/Exceptions.php" file (note the "s"), a limited set of files for grouping purpose "MyPackage/Exception/SomeCondition.php" or a combination of both. If "MyPackage/Exception/SomeCondition.php" is used to group exception sub-classes, then the parent class "MyPackage_E_SomeCondition" *must* reside in "MyPackage/Exception/SomeCondition.php" and not in "MyPackage/Exceptions.php". This is to supress any guess work on where "MyPackage_E_SomeCondition" is declared. Note: there is a potential BC issue when a MyPackage_E_SomeCondition originally in "MyPackage/Exceptions.php" is moved to "MyPackage/SomeCondition.php" to satisfy the rule above due to grouping of newly added sub-classes. The BC issue is for developers other than package maintainers who extend MyPackage_E_SomeCondition and rely on a include_once('MyPackage/Exceptions.php') statement. However, I don't see why such a thing would occur. If the developer doesn't want to use these convenient declarations, then he/she *must* follow PEAR CS for class file hierarchy, with the exception of the "Exception" sub-folder being fully spelled out, instead of the "E" short hand used in the class name. I think this is minor stuff that can easily be settled, be added to the RFC and removed from the "your RFC doesn't address that" list. This gives for some freedom for the developer while limiting the places to look for for exception declarations... In spite of some having jumped on the band wagon to raid the train, I think great work have been accomplished in a reasonable amount of time given the topic. Great work guys!!! -Philippe