Re: Mail_IMAP 2.0.0 alpha 1

Lukas Smith wrote:

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.

This is crazy talk. :) Of course Exceptions are not fatal errors! Have you ever used them!? Yes, uncaught exceptions will raise a fatal error, but it is your job as application writer to catch them. This is simply an elemental part of programming in PHP5. Saying exceptions are fatal errors is like saying that global variables can't be used inside functions.

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.

Yes, and forcing a user to handler errors is wonderful. Thanks to forced error handling, PHP5 code will be a lot less buggy. How in PEAR error can you enforce handling? By forcing your app to die()? I don't know any practical way to use a callback so that PEAR errors can be handled in the way that exceptions are 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.

Simply not true, Lukas. It does not take any longer to write code that uses exceptions. In fact it probably takes less time -- certainly fewer lines of code -- since you don't need to check return values at every stage. If by "rapid prototype" you mean writing code that uses no error system at all. Then you could just as easily do that in PHP5 with one top-level try/catch block to handle your exceptions. This "rapid prototyping" should not be used as a reason to compromise the quality of PHP applications. Furthermore, in my experience there is no negative impact of using exceptions in development time. I would say the opposite is true in my case. Certainly when it actually comes time to test, debug, and track down errors Exceptions save *huge* amounts of my time.

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.

Choice for what? The only choice that exceptiosn kill is the choice to be ignorant of errors that are being thrown by your application. You can always ignore errors with exceptions, you just have to be explicit about it. This is how it should be. I completely disagree with the idea of building applications where ignorance of errors is built into the design. Sure your site may work OK if that one query fails & you have no idea that it failed, but is that really the type of development you want to enable -- nay, require! -- for PEAR? You will see when you use exceptions that they are a huge timesaver -- especially when it comes to debugging an application. It's a night & day difference between Exceptions and PEAR_Error return-style error handling in terms of locating the source of a problem. Exceptions are not fatal errors, they are must-be-handled errors and there is a huge difference. Hans