Re: Exceptions - A new slant to the argument

Hi Davey,

Lukas emmited an example of using exceptions if an option in an array is missing, lets take a look at this for a second. A developer MAY choose to throw an exception at this point - but this exception should NOT reach the user in this form. The exception should be caught by the developer internally in the package.

A quick response. Take a look at the wiki page under the section "Exceptions are Catch-Oriented". The idea with exceptions is that low-level packages don't know the severity. It's up to the calling code to make those types of decisions. I think this "consistency with flexibility" makes a very good model for n-package collaboration. Feel free to outline some of these issues in the "disadvantages" section of the wiki. Bear in mind, though, that there may be simply a philisophical difference here. Exceptions are catch-oriented. I think this feature facilitates using shared libraries; you may disagree. Lastly, I don't think that the developers vs. users distinction is very useful here. "Users" are simply developers using PEAR packages in bigger projects. They are people like you and me, building a complex application and wanting to take advantage of existing code before rewriting it. The PEAR libraries are just one of many cogs in the wheel. These "users" are people that are going to be using exceptions in their PHP5 applications anyway. Hans