Re: Re: PEAR_Exception in CVS

Alan Knowles wrote: > >>> Missing from it: >>> a) printf() type messages for arguments: (needed to enable >>> translatable messages) >>> >>> Possible solution:? >>> throw new PEAR_Exception("mymessage", MY_ID) >>> throw new PEAR_Exception(array("my message %s",$somearg), MY_ID) >> >> >> Umm, this would need to accept that params and accept something a >> callback for actually doing the translation no? Why not pass directly >> the translated string? > >I guess since translation is not something you really want to mess >around with when writing and maintaining the class/packages. The idea of >being able to add a translation hook in the error handler would allow >those who wanted to use translated messages, a simple mechanism to do it. > >eg. >PEAR_Exception::translator(array(&$translator,'get')); >PEAR_Exception::translator('gettext'); >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. >> - 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. Bertrand Mansion Mamasam