Re: PHP5: PEAR base Exception classes

Hi Hans Lellelid! You wrote: >>> 1) people shouldn't be forced to use it, and >> Disagreed. If people use exceptions for their PEAR packages, they'd be >> forced to derive it from the PEAR base exception. > Why -- what is the advantage to requiring PEAR classes to extend a base > exception class? If Exception does everything you need, why introduce a > dependency? If it doesn't do everything needed, than what are these > other requirements -- and why weren't they lobbied for inclusion in > built-in Exception class? The main benefit is, that people can simple catch all PEAR_Exceptions, if they like to. I know, that this is not the goal of exceptions, but there may be places to do things like that. Imagine you are using HTTP_Request to check if Websites are up and write the results into a database. Imagine further on, that you do not really care, if that all worked, or better, don't want to let the user know. Usually you would have to catch the exceptions singely or catch all. That might not be desired, if you throw one once. Having all exceptions in PEAR derived from a base class does not hurt in my eyes and can be a huge effort if someone starts implementing a cool new feature for exceptions in user space. Who knows? >>> 2) I anticipate a number of base exception classes, so it would be >>> good if it were anticipated in the beginning that there will be more >>> than one. >> Having an architecture for multiple exceptions sound good, but I cannot >> see, where the effort is. An exception is just 1 class. > It's not effort, just planning. That's why I suggested having a > directory for exceptions. Hmm... usually we do not regulate the structure of peoples PHP dir structure, except the naming conventions. If we regulate this (also I still can not see, where the benefit is here), it should be "Exception/" and not "exception/". >>>>> Would there be an 'exceptions' package? >>>> I don't think that this is the way to go. A base exception class >>>> should be >>>> included in the PERA package. Making a new package and generating new >>>> dependencies sounds overhead to me. >>> Yup, ok. I think I agree with that too, but also anticipate new >>> 'base' classes & was unsure how a multi-class solution would be >>> handled. IMHO: >>> /usr/lcoal/lib/php >>> |- DB.php >>> |- DB/ >>> |- Calendar.php >>> |- (etc) >>> |- exceptions/ >>> | |- NestableException.php >>> | |- IOException.php >>> | |- ParsingException.php >>> etc. >> I don't know, if we should force people to use a specific directory for >> their exception classes. Where's the benefit for that? > Any package can create their own Exception subclasses. This would be > for the PEAR common Exception classes, which a package could elect to use. So, we need a new installer role "exception". That's ok with me (hoping that people will not flood that directory with exceptions). Or do you mean just to proved these classes with PEAR by default? >>> For individual components this makes sense, however. For example, in >>> my Propel library all methods throw PropelException -- this is useful >>> for performing selective catching in a big framework. PropelException >>> also provides the functionality of NestableException but the primary >>> raison d'etre is just to differentiate those exceptions from others >>> that might be thrown at higher levels in the application. >> I would like to see all exceptions throwen in PEAR be derived from the >> PEAR base exception. It can only be usefull to have that. > Why? It won't be useful (i.e. provide any useful information) to > calling code if all PEAR classes are derived from same base class. If > I'm using Log2, MDB3 (or whatever MDB will throw exceptions), and other > Package_X is there any advantage to my app being able to selectively > catch on PEAR_Exception? I don't think there is. Catching on > MDB_Exception or Log_Exception (etc.) , however would be useful if these > classes had their own exceptions. These conditions don't exclude each other. Having a PEAR base exception and the MDB3,... -whatever- exception derived from it doesn't hurt. And, as I said, who knows, if in 2 weeks someone come up with the best userland exception extension ever seen? >>> At the heart of it, I think that PHP5 is a great opportunity for PEAR >>> to become a component library rather than a quasi-framework. With >>> PHP5 the framework aspects of PEAR seem completely obsolete, since the >>> framework components exists to compensate for lacks in the language -- >>> error handling, destructors. The fact that PEAR has this framework >>> means that building a project with PEAR classes forces you to >>> subscribe to that framework and makes it difficult to integrate single >>> PEAR packages into an otherwise non-PEAR architecture. >> Disagreed. I especially like that common things in PEAR. No matter which >> component you use, you just have to check PEAR::isError(). That's >> useful, not overhead (alos the error objects are). Same thing would be >> with exceptions. > Yes, but PHP5 has built in PEAR::isError() called catch() -- you don't > need any framework functions to do: > > } catch(Exception $e) { > Why stick to using a framework that duplicates built-in language features? It doesn't. It just wraps around and enables us to add more functionality, if desired. If there's nothing to add: It will not hurt! And I still see an advantage in allowing people to catch all PEAR exceptions at once, if they like to. If they don't: It still doesn't hurt. Regards, Toby -- Tobias Schlitt a passion for php http://www.schlitt.info