Re: Mail_IMAP 2.0.0 alpha 1

Hi, Klaus Guenther wrote:

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?

As was already pointed out by me, the sheer amount of QuickForm questions demonstrates that one can safely ignore current PEAR's toothless "error handling". Ever seen if (DB::isError($db)) { ... vs if (DB::isError($res)) { ... also? I am for exceptions: they will make it impossible to ignore errors. You can ignore errors if you are a guru, but the webmonkeys *should* check the errors.