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

I think Matthias Nothhaft wrote:

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.

This is a problem.

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).

Some errors are located in odd places. For example, when phpDocumentor "throws" an error (I use throw loosely here), the location is never on the line that the error was discovered, but in a source file that was being parsed. A database error's location is in a query string passed, or in the database itself somewhere. Very few errors are located in the source code, and in fact, every error that is located in the source code should be an exception by definition.

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...)

This seems overkill to me. define() was invented to make this thing unnecessary. I think naming conventions are a possibility from a theoretical standpoint, but should be limited to error prefix. As long as every error code is well-documented (this goes back to your first point, laziness), it should be possible to name it anything descriptive. It is possible to have a standard set of error constants used that have the PEAR_ prefix, so that if one of a number of standard file-related or input-related or database-related errors is encountered, the program can be written to accomodate them. However, I don't think a generic solution is a good idea, for the same reason error messages need to be error codes: not knowing specifically which error codes correspond to which error situations is a really bad idea. If you get an error code that says "file not found" and only know which function returned it, that's not very helpful. You need to know in what context the file not found error occurred, and this means a more specific error code associated with error messages that can be changed, but the meaning should remain. I would like to see something like $e = $class->doSomething(); if (PEAR::isException($e)) {

    return $e;

} if ($warnings = PEAR::caughtWarnings()) {

    PEAR::displayWarnings($ui, 'displayMethod');

} or better yet, the exception-checking code happens as normal, and the warnings are displayed at another appropriate time, or even just logged. Greg