On 11/3/13 2:57 PM, Gilles wrote: > On Sun, 03 Nov 2013 21:03:02 +0100, Luc Maisonobe wrote: >> Le 03/11/2013 20:17, Ted Dunning a écrit : >>> On Sun, Nov 3, 2013 at 10:56 AM, Luc Maisonobe >>> <l...@spaceroots.org> wrote: >>> >>>>> I had proposed that error messages be incrementally built from >>>>> simple >>>>> "base" patterns, to be assembled either at the point where the >>>>> exception >>>>> is going to be thrown or inside specific exceptions[2] (or a >>>>> combination >>>>> of both). >>>> >>>> It often doesn't work. Sentences constructions are completely >>>> different >>>> in different languages, and it is impossible to simply buid up >>>> from >>>> elementary components that are individually translated and >>>> assembled >>>> later. See all the documentation about the ancient gettext for >>>> example. > > I think that a message good enough to convey the cause of the > failure can > in many cases be built from such blocks. I concede that it may not be > perfectly formulated in a natural language, but even if it where, > the error > message are _rarely_ if ever clear,
I disagree with that statement. I think we have in general done a pretty good job producing clear, understandable exception error messages, which are very useful to users of a library. For the code I work on, I will continue to do that, whatever contortions are required to create them. I personally don't mind working with the message pattern setup we have. The one improvement I would appreciate / incrementally help with is an attempt at organizing them a little better. Phil > an one needs to refer to the apidocs > in order to understand what caused the exception. There the error > condition > is hopefully (as it should) explained in a nice and clear sentences. > > There are drawbacks in having these hundreds of messages patterns. > >>> >>> >>> Modern printf implementations deal with this by numbered >>> arguments. This >>> is not a problem any more. >> >> Which means you have a complete message with a sentence that >> simply has >> placeholders for variables parts. What I understand about Gilles >> proposal is to go further in the way of small blocks like >> COLUMN_INDEX, >> CONSTRAINT, EVALUATION, INDEX, NORM, and build up from there. Is >> it what >> was initially meant? > > Not sure I understand what you wrote. But, yes; where a > juxtaposition of > the blocks is good enough, we could readily use it. That will > reduce the list > quite substantially. When we get rid of all the similar patterns, > it will be > more acceptable to keep a few longer patters where really necessary. > > > Regards, > Gilles > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
