Re: Standardized way of interpolating variables into PEAR_Exceptionmessages?

On 2006 09 25 09:16, Bertrand Mansion wrote:

Alan Langford wrote:

On 2006 09 24 13:44, Justin Patrin wrote:

On 9/24/06, Alan Langford <jal@ambitonline.com> wrote:

One of the problems with most error/exception mechanisms is that they have a real inclination to take all the semantically meaningful data, jam it into an unparsable string, and pass it back as an error message.

1) Error message strings have to be there in order to give any useful information to the developer.

Just one point of clarification. There's no way I want to replace the text message. I was suggesting that in the event of an error that might be described as "Error 15: Permission failure in process 'foo' while executing method 'bar'", that the exception have contents similar to this: ['code'] = 15 ['message'] (as above) ['process'] = 'foo' ['method'] = 'bar' This makes it a lot easier for someone doing I8N to prepare their own message, after understanding the English version, of course. My suggestion was that we strongly recommend (if not require) that packages pass all data used to assemble a variable error message as separate components of the exception, thus making the I8N process far easier. Thanks for your other comments, I am beginning to get a better handle on all of this now.

Well, with Exception itself you already have: - code - message - line - file - trace And with PEAR_Exception, we added: - class - method or function - cause - custom error data Have a look at the code <http://cvs.php.net/viewcvs.cgi/pear-core/PEAR/Exception.php> Good luck, -- Bertrand Mansion Mamasam Tel : +33 1 48 89 88 26 http://www.mamasam.com Creative Internet Solutions

My apologies, my example sucked -- an attempt to be too general. Perhaps 'table' and 'column' from a database-centric package would have been better (there's lots of times when I wished my ODBC driver returned stuff like that instead of a kilobyte of hard to read text). What I'm trying to advance is more of a general coding principle that would make the original issue in this thread, I8N, easier. The "interpolation" should be an application level responsibility, but the exception should give the application developer the information required to meet that responsibility without being forced to try to extract the semantic information from an unstructured error string.