On 11/4/13 2:08 AM, Luc Maisonobe wrote: > 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.
I have scanned for exact duplicates quite a few times and never found any. There are quite a few that are similar, but differ in material ways (strict versus non-strict inequalities, endpoints included / not included, etc.). Please do not "collapse" messages at the expense of loss of specificity or correctness. Phil > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
