Re: PEAR's Error Handling and PHP5

From: Date: Wed, 07 Jun 2006 21:22:45 +0000
Subject: Re: PEAR's Error Handling and PHP5
References: 1 2 3 4 5 6  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-42845@lists.php.net to get a copy of this message
Hans L wrote:
I really don't want to revive a silly debate, but can you provide some concrete examples of how using exceptions in place of PEAR_Error would actually make prototyping slower? I know you've been saying that for years, but it just doesn't make any sense to me. In fact, I would say the opposite is true in my applications. I can only assume that you simply haven't used exceptions -- but I'm willing to be wrong!
Say you generate a report page. There are multiple graphs that are atleast partly generated from the same database tables. Now you want to change a single one of them that requires messing around with the table schema. Obviously this will break at least part of the other graphs. I do not want to spend a single second on those graphs however. So I do not want to start having to uncomment code, add a catch block around them. I just want to see how that single change will look inside the overall layout. Its irrelevant if the other graphs spout some error messages or simply incorrect data. The point is you have multiple independent methods, modules or whatever that interact on some level that means that you are likely to break one piece when messing with certain things in another. Then again I really do not care what PEAR decides. I am tired of explaining this over and over. This is consuming more time than I am willing to devote to this topic. Maybe I just do things so radically different that I am just different. But it seems obvious to me that the masses want Exceptions. So I am not going to try to stall "the obvious choice" any longer. I will decide if I am willing to use an exception enabled package or not when the time comes and I do not have immediate plans to write a new package anyways. regards, Lukas

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