Re: PHP5: PEAR base Exception classes

Hi Hans Lellelid! On 06/17/04 10:15 you wrote:

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

Disagreed. If people use exceptions for their PEAR packages, they'd be forced to derive it from the PEAR base exception.

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.

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?

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.

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.

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.

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. Regards, Toby -- Tobias Schlitt GPG Key: 0xA6529579 a passion for php http://www.schlitt.info