Re: Mail_IMAP 2.0.0 alpha 1

Hi Jan, > Hi, > On 6 Jul 2004, at 18:17, Hans_L wrote: >> 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. > > big objection here. I choose drastic words now to clarify > my point, take them with a grain of salt. > > PHP 5 is a OO-spiced-up PHP 4 and exceptions come with this > as a nice syntactic sugar. Just because of that, it is > definitely _not_ (!) "an elemental part of programming in > PHP 5". Well, if you don't learn how to use exceptions then your application will have E_FATAL errors if you use any components that do use exceptions. I think exceptions are pretty fundamental change in PHP. I think calling exceptions "syntactic sugar" is very wrong. "Syntactic sugar" that drastically changes the flow of your script and design of your application? I can imagine the same line of reasoning applied to objects when they were first added to the language. Certainly you don't need to use classes/objects in PHP, but they are definitely a fundamental part of the language (evidence: PEAR). > I do think I will carry my PHP 4 coding style to PHP 5 and > thus what I contribute to PEAR. If and when I encounter a > problem that is easily solvable with a new PHP 5 feature > and I am not bound to PHP 4, I will use it, because I am > not a traditionalist, but just because I have PHP 5 at my > hands, I don't go and make use of every new bit of it and > there's hell of a lot more interesting stuff than exceptions > to discover :) Well, the challenge is that when designing a cohesive collection of packages they need to have common error handling. For the first time PHP now provides a solution for user error handling that is particularly suited to the n-layer development style that PEAR libraries facilitate. Exceptions could provide a great glue to make PEAR libraries a coherent interworking whole, a glue that was formerly provided by a kludgy (but certainly best for PHP4) solution: PEAR_Error. This is PEAR's traditional problem. It wants both to be cohesive and to allow freedom, and so developers want both those things too. To require PHP4-style error handling when PHP5 provides built-in proven error handlign with Exceptions would be a mistake. To allow packages to do whatever they want with error handling would probably also be a mistake because it will kill interoperability. In my world, PHP applications are becoming far more complex and multi-layered. I see this everywhere I look, with frameworks obtaining new levels of stability & quality. I see the introduction of Exception as tribute to this new demand for PHP. Indeed Exceptions are not particularly well suited for building flat, quick PHP scripts. They exist for complex OO architectures. PHP5 in general exists for complex OO "enterprise" applications. > Nothing personal here, not at all. Nothing personal taken; It's ok to disagree. :) Hans