Le 04/11/2013 00:59, Gilles a écrit : > On Sun, 03 Nov 2013 15:33:12 -0800, Phil Steitz wrote: >> 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. > > My statement is not that the error message is not a well written > English (or French) sentence. It is that being in a correct natural > language does not help in figuring out what the caller code did to > trigger the error. > The low level cause can be conveyed with the "little blocks" too. > > It seems we go in circles; every time I have to assure that I do > not, and never did, propose to suppress error messages! > > What I suggested is to try and see whether the "ExceptionContext" > can be used more.
Exceptioncontext has been add more than two years ago (revision 1099771, 2011-05-05). Since then its setValue method is called in only two places in regular code (not counting test code): in SymmLQ.java and in ConjugateGradient, so this key/value features seems a failure to me. Its message part on the other hand is used everywhere, and I even use it outside of Commons Math since I introduced the ExceptionContextProvider interface in September 2001 (we had a short discussion about it there: <http://markmail.org/message/q7gv5mqx62w735pc>). So I agree ExceptionContext is a useful class, and perhaps it would need some changes. As per the comments above, I would suggest to further improve the used part, typically allowing to retrieve the patterns and arguments which I really miss, as the patterns are already set everywhere and can be used externally to also identify a particular exception. I have no real idea about improving the currently almost unused key/value feature, but fear it would imply a tremendous work. > >> 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. > > That was the purpose of my suggestions, which came up to implementing > the "ExceptionContext". > Again, this may not be the answer to all wishes in matter of conveying > error information, but how will we know if we don't even try? > > It is quite possible that many duplicates ended up in the error > message list just because it was easy to miss the one that should have > been reused or that the existing ones where not quite appropriate to > the exception being thrown. This may be true, but finding it is also a lot of work, with little benefit. Feel free to do it if you want, though. best regards, Luc > > Gilles > >> >> 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 > > > --------------------------------------------------------------------- > 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
