Re: Mail_IMAP 2.0.0 alpha 1

Hans_L 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??

Indeed, I think perhaps you are :) What do you mean that an Error is not an Exception? You see them as different levels of severity? An Exception is an unexpected error that should be handled by your application.

Not all errors are fatal. Exceptions are fatal errors. You just get a last chance to handle that fatal error. Therefore exceptions are for enviornment errors. Everything that doesnt work and that you dont control from within your application. Like missing files, database is down etc.

Thinking about having Exceptions raising everywhere sounds like my next biggest nightmare in PEAR ;-)

Certainly not as big a nightmare as returning PEAR_Error objects from methods, forcing the checking of every method return and often resulting in uncaught, lost errors in the system.

With PEAR error you dont get uncaught errors either. Just put in the proper callback. However you are right PEAR error lets you choose if to handle your errors. Exceptions have to be handled.

I would rather have "Exceptions raising everywhere" than have an uncaught error that has hard to diagnose repercussions throughout my app. But realistically, you should never be *expecting* your application to raise Exceptions.

I use PHP because it allows rapid prototyping and lets me develop this prototype cooperatively with my client to the final product. For this to work I quickly need to give the client a feel of what the final application will look like, how it will be organized etc. My clients dont have an interest to pay for clickable powerpoint presentations. With exceptions I have to write my prototype with full error handling in place, which effectively kills off my style of development. I can already here the "just put a giant try/catch block" fraction telling to stfu. Well a giant try/catch works if on error you dont want to display anything. I flawless prototype is even moreso a myth than a flawless application. However the goal of a prototype is to show how the app looks like. Flawlessness is beyond the scope of a prototype. In conclusion: Exceptions kill choice. Choice is flexibility. Flexibility is what makes PHP useful to me. Yes if the database is down I dont need flexibility so an exception is in order. If I screw up a query then its likely that the app will still produce meaningful data with the 10 queries also done on the page. regards, Lukas Smith smith@backendmedia.com _______________________________ BackendMedia www.backendmedia.com berlin@backendmedia.com Linn Zwoch Smith GbR Pariser Str. 44 D-10707 Berlin Tel +49 30 83 22 50 00 Fax +49 30 83 22 50 07