Re: Standardized way of interpolating variables into PEAR_Exception messages?

Hello, On 9/23/06, Alexey Borzov <borz_off@cs.msu.su> wrote:

Hi, Dan Scott wrote: While working through my PEPrs, I converted my PEAR_ErrorStack error-handling to PEAR_Exception in accordance with the RFC for error-handling in PHP 5 packages. But one thing that I seem to have lost in the conversion is the ability to interpolate variables into the messages that I pass to PEAR_Exception. I was looking for something akin to the PEAR_ErrorStack templates. Currently, it seems like every package is responsible for its own interpolation -- so a typical usage would be something like: if ($var < 0) { throw new Foo_Exception("The value of VAR cannot be '$var'."); } The problem with this approach is that it becomes very difficult to internationalize the message strings -- which is why, in my definition for File_MARC_Exception near the bottom of http://marc.coffeecode.net/highlight_MARC.php, I've defined the error codes as class constants and a static array of messages with the error codes as the keys to the array. What's wrong with more-or-less standard throw new Foo_Exception(sprintf(_('The value of VAR cannot be '%s'), $var)); why reimplement it? And why it is reimplemented in ErrorStack in the first place?

_() has nothing standard. We never provide localized messages either. I also don't think we should provide them. Errors messages at this level (a library) are for developers, not end users.

Ah... and I've just been told on IRC that the RFC requiring PEAR_Exception for PHP5 packages, although "approved", is not necessarily a requirement after all. It might be nice to edit "approved...but despite that, not agreed upon or required" proposals to reflect their true status. I'm just trying to strictly follow all of the coding standards for my proposals as best I can. That's complete and utter BS.

Alexey, again, keep such words out of this list.

The proposal is either accepted or not, whether the anonymous person on IRC likes it or not.

And I confirm that this pepr is not accepted. We are not going to accept such changes with five +1, we never did and we will not start now. A large participation and agreement is required. --Pierre