Re: Mail_IMAP 2.0.0 alpha 1

On Tue, 06 Jul 2004 19:48:00 +0200, Klaus Guenther <klaus@capitalfocus.org> wrote: > Lukas Smith wrote: > > > Pierre-Alain Joye wrote: > > > >> On Tue, 6 Jul 2004 15:00:56 +0200 (CEST) > >> tobias@schlitt.info (Tobias Schlitt) wrote: > >> > >> > >>> As said before, I agree with your argumentation, but I still > >>> insist on forcing people to a common error handling method (let it > >>> be PEAR exceptions), to keep our usability level. > >> > >> > >> > >> Am I the only one thinking that Exceptions are a specific > >> """Error""" (let add as many quotes as you like) but an > >> Error is not > >> an Exception?? > >> > >> Thinking about having Exceptions raising everywhere sounds like my > >> next biggest nightmare in PEAR ;-) > > > > > > You are not alone. However it seems "we" are alone :-) > > The trend seems to be unstoppable. So I guess we need to adjust or > > move on. > > > I agree with both of you. And to be quite honest, I wonder if this isn't > something the Group should decide because it has profound impact on the > future development of PEAR. One thing that will put off a lot of users > is the fact that they will need to try/catch every single call to a PEAR > package. This is a misery I don't think we want to subject our users to. > Also, exceptions raise the huge problem that adding a new type of > exception will be a major BC break, while adding a warning or something > that wouldn't die would not. > > A good portion of the beauty of PEAR is that the code is consistant. If > we have umpteen different ways of handling errors (not to mention all > the pain that throwing an exception in each method brings with it), PEAR > will not have much of a future. After all, as Stephan pointed out, a lot > of users use PEAR because they are not able to write solutions > themselves. The sheer amount of QuickForm questions demonstrates this. > Do we really want to go through the torture of explaining why an > application dies unexpectedly? Granted, with exceptions you do have a > bit more detail, but if people don't even know how to read the > PEAR_Errors, who really thinks that they'll be able to do anything with > exceptions. Consistancy is of utmost importance as well as keeping the > interface simple. If it takes me a week to figure out a package's API > (including all the exceptions that may be thrown), I'm probably going to > hack together my own version. Even if my version lacks the finess and > portability of the PEAR package. > > And just because exceptions exist doesn't mean that they should be > overused. Just because guns can be used to shoot people doesn't mean you > should get a gun and shoot people. > Very well said. This is exactly why I proposed an addition to PEAR::raiseError (or PEAR_ErrorStack or whatever) that simply adds a new error mode, PEAR_ERROR_EXCEPTION, which would throw a exception instead of returning a PEAR_Error (or calling the callback, etc.). This way, each developer can choose to use Exceptions or PEAR_Errors as they wish. PHP4 packages can even throw exceptions in this case (as they would still use raiseError when used in PHP5) and PHP5 packages can return PEAR_Errors if the developer so wishes. If a package does internal error checking, it can also choose to use exceptions or PEAR_Errors as the developer chooses. This is the point of push/popErrorHandling(). Letthe user choose. As I have said many times before, this would entail *1* extra funciton call and *1* extra switch statement and *only when an error happens*. It would be minimal code when used in PHP5 and allow any developer to choose their error handling style, whether it is in the application or a PEAR package. -- DB_DataObject_FormBuilder - The database at your fingertips http://pear.php.net/package/DB_DataObject_FormBuilder paperCrane --Justin Patrin--