Re: PHP5: PEAR base Exception classes

Hi again, Tobias Schlitt 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?

I don't follow this argument, -- at least I don't see why having a common PEAR_Error is useful for people using many PEAR classes (and from my experience most people using PEAR [have to] use all PEAR classes, due to the massive inter-deps). So, my assumption is that catch(PEAR_Exception $e) is going to catch exceptions from lots of different packages, making it essentially the same as catch(Exception) Regardless, I'm also less inclined to think a subclass is evil now :) In particular, I think you could capture that extra flexibility provided by ErrorStack in a base class. If you wanted to have Exceptions all logged for instance, you could establish that by setting some static properties of the PEAR_Exception base class. Ok, so not so bad. I like the simplicify of Exception, myself, and adding abstraction just for the possibilty that it will be useful later seems misguided -- and also typical of many PEAR packages. I think I agree with Alan in that regard; decisions to further abstraction should be based on real-world needs & not hypoetheticals that will never materialize. I'm not suggesting that the need for abstraction in the Exception system is hypothetical, merely that it needs to provide some value in order to exist. For one thing, using Exception now and adding a PEAR_Exception class in the future when it is actually needed will break no existing code -- since PEAR_Exception instanceof Exception.

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?

Actually, I don't think so. I'm sorry if my note was unclear. I was just saying that there should be a package or place for *base* exceptions. Other libraries can just have their exceptions in the same location as other class files.

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.

I know but adding a dependency of this scale for all packages shouldn't be such a trivial decision, IMO. You're not just suggesting that the class exist, but that it actually be a requirement for all PEAR packages to use it. I think such a requirement should be carefully thought-out and properly justified, that's all. Abstraction "just-in-case" is bloat. Hans