Re: PHP5: PEAR base Exception classes

Tobias Schlitt wrote:

Hi Hans! You wrote: Hi,

I think it would be great if PEAR provided some re-usable base Exception classes.

I posted this idea a few weeks/moths (dunno) ago...

Yeah, I do remember seeing this before on the list.

I see a huge benefit in having such a class, since people then can catch any PEARException, if they want to, to just indicate that an exceptional state occured inside a PEAR class.

I agree -- though I would add two things: 1) people shouldn't be forced to use it, and 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.

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.

How does one propose code that goes into core PEAR? I imagine that this would be in something like an 'exception/' dir, but, again, I don't see any reason to add a prefix as that would be completely redundant (and make using them just more cumbersome).

I did not really get that point. Can you explain it once more to me?

Sure, but I don't think it's really relevant anymore. Basically I was saying that even if it's a package, prefixing all Exception classes w/ 'Exception' (or whatever) seems rather redundant: } catch(Exception_IOException) { // yuk It sounds like you are suggesting PEAR_Exception, but I think the base class should describe the function instead: NestableException <-- allows nesting LoggingException <-- provides automatic logging How will PEAR_Exception be special? One argument might be that you want all PEAR classes to be throwing a commonly derived Exception object, but this doesn't really make sense to me given the number and wide variety of PEAR libraries. -- i.e. having a PEAR 'type' of exception doesn't really specify anything useful in itself. 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. So, a DB_Exception or MDB_Exception would make sense to me but PEAR_Exception doesn't really unless it provides some special functionality -- in which case I think the name should reflect that functionality. And if it does a whole bunch of things, then perhaps it should be multiple base classes and/or interfaces (although I don't think you can catch() interfaces, unfortunately -- have to check on that one). 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. Just my .02. Hans