Re: exceptions

On Jun 8, 2004, at 2:14 PM, Lukas Smith wrote:

Hans Lellelid wrote:

Yes, it does force users to do error handling. There's nothing to argue there; I think that's wonderful. (finally!) The current model makes it all too easy to lose errors if you forget to check a return value. And makes it impossible to establish code "transactions" that should fail on error.

Sometimes you have to stop and think why you are using PHP to begin with. I use it because simple things can be done rather simple and increasingly complex things are also possible with reasonable effort. You are argueing that everything should become complex. That is not why I choose PHP and I doubts its why PHP has become successful. PEAR does aim to provide solutions to a wide audience, including beginners. We define how we want to code, but we have no mission to define how other people have to code. This is not in the spirit of a library. That is not to say that we should try to set good standards that other people may choose to adopt.

I agree. On the priority list there are the coding standards, better end user documentation etc. While I have been using PHP 5 since the first beta (and adapted my code style accordingly) I never used exceptions nor I think they will bring something substantial to me. Of course if someone wants to use them, not a problem but becoming a standard would be a totally different thing and as Lukas said you will be like telling people how to code and what to use.

Exceptions also enable very tricky goto style code flow handling. While some people claim its ok to use exceptions for code flow as long as they dont leak out of a defined self contained piece of code, but I strongly disagree. Any mistake in this misuse of exceptions will lead to a fatal error as the exception is likely to remain uncaught.

I would say that the code flow provided by exceptions is extremely logical, as compared to the hoops you have jump through to achieve the same effect if you do not use exceptions. An exception should never remain uncaught -- there's just no reason for that. API documentation indicates which methods throw Exceptions and it is the responsibility of the person using that method to have the necessary try/catch checking somewhere in the call stack.

Err, well this is indeed philosophical, but its hard to make a case that goto style programming is easy to follow. I have yet to see an example where you can't break out of the context in a clearer manner. Actually I was sitting in a session grom george in Amsterdam and I had a hard time following a code example. Turns out he was using an exception for code flow. Very nasty imho.

The real documentation on exceptions is really bare bones (http://www.zend.com/manual/migration5.oop.php) so I really doubt that it will become widely adopted anytime soon.

Now the question is are the alternatives really that much uglier. I think not.

Reminds me of an Eddie Izzard skit (I think original was about UK in the EU) ... PEAR is not in the driver's seat of PHP development, nor is it in the passenger's seat; it's outside along the side of the road picketing against using exceptions and object inheritance.

Bashing will not help your argument. It will actually make the likelyhood you get taking seriously smaller. Bashing PEAR might however make you more expected outside of PEAR (they are a fair amount of people who feel its necessary todo so).

There will always be someone saying something like that about PEAR. I have read similar comments online yet I have seen few to say "let me help and let's improve X or Y". At the end of the day we have to please the users and to provide quality libraries. Pleasing every PHP developer it's really not the point on PEAR. Cheers David Costa