Re: Mail_IMAP 2.0.0 alpha 1

Lukas Smith wrote:

Err, exceptions are fatal errors that you can catch before they kill you. Nothing crazy about that argument.

Ok, but then it's no different from PEAR_Error. Check the return result before you use the object or you will have a fatal error. By that reasoning all returned PEAR_Error objects are also FATAL errors.

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.

You can. Set a callback to have pear die() on error and then set the expected errors before you make the call. Not very efficient from a performance aspect, but not really that much more code.

OK, I should have clarified that by "handle" I mean intelligently handle an exception. Developers are required to intelligently handle errors when using Exception. die() may be useful during development when you're not handling anything -- it's essentially the same as a uncaught exception -- but it is not a strategy for handling errors.

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.

You have a hard time reading what I said. So here to spell it out for you once more: 1) Phase 1 Prototype 2) Phase 2 Cooperative development I want to get to 2) asap and I dont care how many errors the app has at that point as long as my customer gets a better understanding of the to be expected end result.

I read what you said, Lukas. You feel that it takes longer to prorotype something w/ Exceptions & I said it's just not any different from PEAR_Error. Perhaps your idea of a "quck and dirty" application is different from mine. We all have our development methodologies. But as far as I can see if you do not check return types on a method that may return PEAR_Error you are 1) just as surely going to get a FATAL error and 2) you are gonna have no idea what the error is about until you go in and add handling code. With exceptions you have a head start because you know what the problem is when it bubbles up.

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 case you didnt get it .. you are part of the "just put a giant try/catch block" fraction. Please go back and read what I wrote.

Yeah, I'm not actually part of that faction. I do believe, however, in having relatively few entry points to an application. That try / catch is not giant, but is at a high level. Many lower try/catch blocks add context. For instance you would put try/catch blocks around code that calls model objects from your controller layer ...

You design with the idea that you write and deploy. I design with the idea of write/discuss, deploy. Of course I care about everything error before I deploy, but I dont care about every single error while I develop. However with PEAR Error I can easily know about every error that occured in my application. Also note that I dont care so much about exceptions in general but execeptions that leak out of the a given package.

"Leak" out? You mean like the way packages return PEAR_Error?

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.

Its not. Exceptions have their uses. If I was developing using UML, nice powerpoint mock up apps then I would probably agree with you: put exceptions everywhere. But I am not and I dont think that I am such an exotic PHP developer. However once a hype is rolling its hard to stop it. Actually while I care about PEAR I dont care enough to fight this topic endlessly. Especially with people whi dont even give me enough credit to read what I write.

Heh, then by that last line of reasoning, I also don't care to further try to explain how exceptions work to someone who hasn't used them... Hans