Re: Re: common error handling problem -

Matthias Nothhaft wrote:

Getting the error code parameter (ecp) as required isn't so easy becaus the ecp stands at the second position in the method definition/implementation... To really make it required the parameter should/must be the first one. We must substitute the $message and $code parameters. But that means each package had to be changed - bad... A fast fix can be that all error methods with $message and $code parameters are 'tuned' like that: - $message and $code are substituted - an "auto detection" checks the type of $code and $message -> "integer" means the input is a error code -> "string" (and other?) means the input is a error message - only if $code AND $message are no integer a warning/notice is triggered

interesting idea. I think the best solution is to maintain some backwards compatibility, and simply require both a message and a code. The PEAR class is on the edge of severe bloat as it stands, and any unnecessary additions to the code should be avoided.

A little question: Is it possible in php5/ZE2 to make each parameter of a function/method optional or not?

If I understand the question, php 4 has this facility function mine($option1 = null) {

    if (!isset($option1)) {
        // optional if allowed
    }

}

And what about localizing the real error source for example in situations where an error is passed by an inherited class/object?

Give me hint how to implement it, and it will be done ...

your idea of addUserInfo() is nice but it should also contain a info where the addition comes from...

If the RFC is accepted, then you will be able to figure out the ultimate error source from getType(). However, if an error is converted to another error along the way (DB throws an error, which is caught by DataObjects and repackaged to describe what DataObjects was trying to do), then there is no way currently to retrieve the old DB_Error from the DB_DataObject_Error. The best way to do this is to allow userinfo to be a PEAR_Error object. Then we can nest PEAR_Errors when they are re-packaged, and once again without changing a single line of code (only the documentation) Regards, Greg