Re: Re: PEAR_Exception in CVS

Bertrand Mansion wrote:

Alan Knowles wrote:

or better, just make the translator a special observer.. (although it does more than observe!) - keeps the API kiss.. and thin. PEAR_Exception::addObserver('translator','gettext'); PEAR_Exception::addObserver('translator',array(&$translator,'get'));

Observer -> Decorator ? Looks more appropriate in this case. Still, if you maintain a database of error translations where an error code is linked to an error message, you'd just need to know in which language the application is running and which code has been triggered. So you wouldn't need decorators or observers as you call them. In order to keep it simple, just give an error code and it is up to the user to define the needed translations according to the given error codes and their meaning, which are of course documented. So no printf, no error message, just an error code.

Dynamic error messages are in general much more usefull (and recommended) than static ones.

- A static method for pushing errors in the internal stack - A static method for getting the array of warnings - Ability to attach observers to warnings too.

PEAR_Exception::addObserver('warning',PEAR_OBSERVER_TRIGGER);

I don't think warnings belong to PEAR_Exception at all.

It's a nice addition to have a default (and hopefully common) warning handler. Just to avoid the case Greg illustrated with each developer using it own. Doesn't hurt at all. Tomas V.V.Cox