Re: exceptions

From: Date: Tue, 08 Jun 2004 13:34:29 +0000
Subject: Re: exceptions
References: 1 2 3 4 5 6  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-30166@lists.php.net to get a copy of this message
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.
Yes, perhaps that is a difference, then. I actually use PHP because it's quick, easy to integrate with Apache, and now has good OO support. I build very large projects & I think I'm the kind of user that PHP5 is made for. I also think that I'm the kind of user that tends to use PEAR packages. These beginning PHP users you speak of don't really know anything about PEAR and perhaps in 6 months or a year will start trying to creat a db abstraction layer only to have someone say to them "have you heard of PEAR::DB?". At that point they're not beginners anymore.
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.
Again, PEAR is not for beginners unless by beginners you mean people who are familiar with object-oriented development, templating in PHP, understand the need for db abstraction ... etc.
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.
Yes, I guess it's philosophical. Exceptions are certainly different than return-value based errors, but just because you don't feel comfortable following code that uses exceptions doesn't mean that PEAR classes should avoid them. Again, documentating exceptions in the API might help ...
Now the question is are the alternatives really that much uglier. I think not.
Yes, the alternatives are far uglier as they require many more constructs -- whether if/then or conditional premature function return, etc. They require many more lines of code and accomplish far less.
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).
I'm not bashing PEAR, I'm laughing at it. :) j/k ... well, to be precise, I'm laughing at these ideas that exceptions are bad because they're different and encapsulation is bad because it adds methods. Plus, the analogy is really funny to me. Don't get me wrong, I'm not criticizing PEAR; I'm criticizing what to me are very dumb-sounding proposed policies. I think that I and many other PHP developers have been excited to see PHP5 do away with conventions like PEAR_Error -- which admittedly is a good solution for PHP4 (not as good as ErrorStack, but still pretty good). PEAR certainly is a leader in the PHP community in certain regards -- or at least one regard: the PEAR coding style guide. PEAR doesn't want to be a repository for cutting edge software, though, and the package prerequisites, style guide, proposal process, emphasis on unchanging APIs, help ensure that PEAR is a repository for the "tried & true". Doesn't seem to be anything wrong with that. So stop getting defensive :) What I am criticizing is not PEAR, but what I consider to be a very reactionary attitude toward new OO practices that PHP5 makes possible. I have a couple packages that I've been slowly preparing for PEAR proposal & they will be PHP5-only packages that use Exceptions. Of course whether they are voted down based on that is entirely up to the devs, but I'd certainly like to not see policies that preclude that type of packages. Hans

« previous php.pear.dev (#30166) next »