Re: Exception misinformation

Hans_L wrote:

1) Exceptions are not FATAL. They are designed to be caught; for an exception to become a fatal error is for a programming error to have been made (i.e. not catching). Calling private methods from outside of an object context also results in an E_FATAL error; does this mean that private methods are fatal? And, as mentioned below, forgetting to call PEAR::isError() on a returned object & then attempting to invoke a method will also result in fatal error. Is PEAR_Error also only for fatal errors, then?

Your analogy is lacking severely.

2) Using exceptions does not mean wrapping every method call in a try/catch block. The idea with exceptions is that they allow you to group things into logical units -- think of business transactions, or Transaction Script pattern. try/catch blocks only need to exist where you want them to exist. It allows you to decide what contexts are relevant for exceptions.

Yup, this is an appealing way of using exceptions.

Applications (particularly ones that use PEAR) are built in layers. The strength of exceptions is that they move up the layers without needing to be explicitly passed. This means that very low-level exceptions can be passed up to high-level calling code with no additional effort by the developer. In some cases that is desireable, in other cases it may be more desireable to catch and rethrow if you want to provide some more information about the error. (As in the hydrate() method, which provides some contextual information to the exception so that the error doesn't simply ready "Illegal resultset offset: 1", for example). In either case, having the exception is preferrable to code that is oblivious.

You can rethrow PEAR_Errors as well :-) Anyways exactly this jumping from one place to another is where things get dangerous, especially if things leak out to the user layer, because as I said then you are forcing the user to handle the exception or they get a fatal error.

5) Exceptions do not require more work than PEAR_Error. Both Klaus and Lukas seem to think that these Exception things are a lot of work. As I mentioned already, with PEAR_Error you are required to do just as much work, if not more.

Again you are not listening. I said to write a quick prototype it takes longer. You seem to suggest that all method calls create new objects, which is not the case. For example since most of the time in the web world my result sets arent that big people in PEAR tend to use relevant wrapper methods which run the query and fetch the results into an array. Accessing an object as an array is not a fatal error.

Hopefully that illustrates that it is never harder to catch or throw an exception than it is to handle a return-code error. Feels silly to explain this, but I do think many people need to see more examples of this stuff (and perhaps use it!!).

You should feel silly for yet again not having read what I said.

OK, there are some more misconceptions too, I think, but this email is plenty long.

I hope I cleared up some of yours with this mail.

Klaus suggested that PEAR group should make a decision about exceptions. I think that would be premature, as apparently the majority of the group have no experience using exceptions for error handling.

Interesting assumption. So you are saying anyone who doesnt agree with you obviously doesnt know anything about the topic?

It's like the frickin' '_' prefix for protected members. It's crazy to think that the prefix requirement could have actually been enacted by people who had no experience with PHP5 (or any other lang that has protected members) with the result that subclasses would be exposing legitmate public members with '_' prefix .... !!

Actually its not at all crazy as I have said in a previous mail it served the same purpose as the hungarian notation .. it does this in PHP4 already and it could have done the same in PHP5. But I see you are unable to see things with different eyes. However to say it again: just because someone doesnt have your opinion doesnt mean they are "crazy" or "unexperienced".

Please folks, do everyone a favor and actually get some experience with this stuff before trying to make requirements for how the rest of us should use it!

Please Hans, do everyone a favor and open your eyes to other peoples point of views. It may even help your own argument because then you can actually adress other peoples needs with your argument. regards, Lukas Smith smith@backendmedia.com _______________________________ BackendMedia www.backendmedia.com berlin@backendmedia.com Linn Zwoch Smith GbR Pariser Str. 44 D-10707 Berlin Tel +49 30 83 22 50 00 Fax +49 30 83 22 50 07