Re: My Experience with PHP5 Error Handling (and possible

Hi, This time really to the list... Greg Beaver wrote:

Let's look from a different angle: enforcing a PEAR_Error-like abomination will not add additional incentive for writing such php5 packages. The packages *will* undoubtedly appear, only the "BC-keeping" solution will leave us with either 2 transitional periods 1) transition from pure php4 to "backwards compatibility" (tm) 2) transition from "backwards compatibility" to pure php5 instead of one *or* useless cruft on all the packages for the foreseeable future. And PEAR which is now rightfully mocked for PEAR_Error will be mocked for whatever sh*t it will accept in place of it.

Obvious problem #1: "People will be forced to use php4 and php5 packages at the same time until there are enough php5-only options to fill that gap. How can we make this as painless for both developers and users as possible?"

Yes, and I see 2 possible solutions here: 1) Use PEAR_Error for php4 error reporting and exceptions for php5, don't mix; 2) Add cruft to make PEAR_Errors and exceptions *look* the same. In solution (2) developers will have to add cruft and users will have to learn cruft, in solution (1) --- no. Which is painless then? I am not talking about packages using packages, I feel that there should be an RFC requiring php5 packages to run under E_STRICT (I see little sense in other possible solutions), I am talking about "applications" or end-user code.

I have plans to remodel PEAR_ErrorStack (as I said in my last message on the subject) to be geared more towards exceptions, and make it more for handling warnings, while preserving an easy transition to php5.

Greg, sorry, but I understand "PEAR_ErrorStack geared towards exceptions" as "Let's make it easier to ignore errors, exceptions are bad as it's difficult to ignore them".

There is no "PEAR_Error-like abomination" here aside from inflammatory rhetoric that serves no useful or even useless purpose.

There *is*: adding cruft to the 'throw' will force people wanting to use PEAR packages use their idiosyncrasies of error handling. We'll have another incarnation of monstrous PEAR.php for which PEAR was bashed for quite some time, instead of getting rid of it completely.