Re: Re: common error handling problem - a PFC issue?

Lukas Smith wrote:

From: Greg Beaver [mailto:greg@chiaraquartet.net] Sent: Monday, July 28, 2003 3:45 AM

Matthias Nothhaft wrote:

Hello to all PEAR-Devs, is there a chance to get numeric error codes in all your packages and all your error returns? The error handling of PEAR is a very nice one. But in my projects I need errors that can be processed by my php-scripts.

I definitely agree that error handling needs a new look - current PEAR error handling is more like exception handling than error handling. Every package should be able to raise warnings and notices without terminating execution in a standard way that allows integrating

package

error handling as well as package code. Error codes are used by most packages, in addition to error messages, although a few packages hard-code English messages in the code, which

is

probably not a great idea. Perhaps a PEAR_Warning class is in order, and PEAR_Notice class? I would also map the existing PEAR_Error class to PEAR_Exception, so

that

raiseError returns a PEAR_Exception. PEAR 2.0 could switch over completely, allowing time to switch all PEAR_Error references to PEAR_Exception. I don't think any change to PEAR::isError is needed,

as

an Exception is an error, and so is an error. The new classes could publish a mesage to a global repository, perhaps

a

static class variable (or emulation for php 4). This would allow both realtime display and collection for logging (I obviously have gotten this idea from phpDocumentor :). The cool thing about PEAR is that

the

CLI could be used to customize display of these warnings/notices for things like the installer, or other applications.

I remember talking to Stig about this 1 year ago. I think he said we should wait for php5 to think about the next step in error handling. PEAR DB used to have a Warning class but that was removed mainly because there wasn't a standard way to return a Warning along with data. In MDB I populate a class property with warnings. Anyways maybe now is the time to refresh this discussion? Regards, Lukas

Hi, "to refresh this discussion" is a good idea ;-) In my opinion the main problem is that some packages contains only error messages without error codes. I do not really think that this fact is solved by php5... It's not the problem of our nice language, but of our lazy programmers ;-) Again: I can not use any package without error codes in professional applications! That's why I think that it has to be a duty for PFC packages to provide error codes (and optionally messages) and a documentation what error codes mean! An example: I'd like to use the Archive_Tar package for an application framework I'm writing on. It only returns error messages and I don't want my users to see them - so I have to write my own Tar-Class - that's bad! But I also see a problem with error codes: What if we have a class/object hierarchy and an error code comes from a "parent's method". -> We need a possibility to get the exact location of the 'real' error (also nice for debugging). And I also think that there must be 'number conventions' for common errors like "file not found" or "eof" or somthing like that - otherwise we'll get the same problem that we now have with function/method names (open, connect...) Another question: Is this the right mailing list for this discussion? or is there a better one? Regards, Matthias