Re: Re: PEAR_Warning proof of concept

Lukas Smith wrote:

Implementing a workaround for a built-in language feature -- i.e. throw() -- for such a questionable purpose just seems like a bad idea.

Here is an example: You have build an application that fetches data from an external source. Now suddenly this external source is down. Still your application provides useful features without this external source, but your application wasnt build to cope with it missing. So now your application craps out until you refactored the entire code ..

Well, in that example it seems very straightforward to just add a try/catch block around the external fetch call ... or a try/catch block to the data-getting layer in general; you'd most probably need one there anyway. It seems that fairly basic application design should ensure that your code can be made to continue functioning if the function of a particular layer stops working. In general, I just strongly disagree with the suggestion of adding a fundamental change to exception throwing (i.e. requiring a custom PEAR function call to throw an exception) in order to facilitate disabling exceptions. I just don't believe disabling error handling is good practice or serves any real purpose (including "RAD") in building PHP applications. In comparison, I also think it would be wrong to require people not to use PHP5's native private/protected var markers and allow access of internal private variables for RAD purposes. If PHP5 is getting in the way of building *your* applications quickly, then stick with PHP4. Hans