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

Alexander Merz wrote:

Lukas Smith wrote:

Actually this discussion may fit better in pear-qa and that is why I am moving it here (dunno what the best method is for moving a thread to a

This is not a topic for qa only, error codes are missing in more then 80% of the packages! (just check the manual) Years ago, i sad to Stig the error code parameter should be required and not optional - no reaction. There is also no requirement for error codes in the CS too. So i would propose to make error codes required as fast as possible.

Making the error code parameter a requirement is indeed a good idea! But to make this backward compatible it should go in 2 steps: 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! and after "a good time" (let's say 3 months?) it should be changed to a real requirement. And what about localizing the real error source for example in situations where an error is passed by an inherited class/object?

Stephan Schmidt wrote: But then we should offer some guidelines on error codes,i.e.

- how to group them (use 1,2,3,4 or 10,20,30) - should constans be defined for each code - how should they be names

Does it make sense to have common numeric values or consts for common errors like "file not found" or "db connection failed"...? Regards, Matthias