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

Alexander Merz wrote:

Matthias Nothhaft wrote:

first PEAR_Error should 'throw'/trigger? a user warning/notice? if there is no error code supplied (null?) (while the error code parameter remains optional) -> I think this can be done very soon!

A lot of users will wonder about error message which are dedicated for maintainers. This is a good idea, because the maintainers will got lots of mails about fixing :-) On the other side this is bad style.

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 A little question: Is it possible in php5/ZE2 to make each parameter of a function/method optional or not?

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... To get the origin of an error we can use the get_class() method. Maybe it would be usefull to store this info with the message given by addUserInfo() Like I said, the most important information is the error code itself! Regards, Matthias