On 11/4/13 10:11 AM, Gilles wrote: > On Mon, 04 Nov 2013 09:47:32 -0800, Phil Steitz wrote: >> 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. > > FAILED_BRACKETING > UNABLE_TO_BRACKET_OPTIMUM_IN_LINE_SEARCH > INVALID_BRACKETING_PARAMETERS
Look at the messages. These are different. They convey different information and are appropriate in different contexts. See below. > > My position: the error (failed bracketing) should have its own > exception > type. The varying contexts could (do not have to) be part of the > message > built at exception instantiation. > > If we want to include an indication of location (despite it is > already > part of the stack trace, so it is _redundant_), we could perhaps > add methods > to the "ExceptionContext", e.g. "where(LocalizeFormats pattern)" (?). > Then, we would have thos patterns in the list: > > BRACKETING > LINE_SEARCH > > Note: INVALID and FAILED are redundant since the pattern is > intended to be > included in an exception. > > > A second "interesting" case is > > INVALID_ROUNDING_METHOD > > which mixes documentation with error description. Does anyone > really thinks > that the enumeration of the rounding methods in the error message > is necessary > or even helpful? When I throw an exception, I want to provide an error message that is meaningful in the context of the caller, i.e., that someone looking at a log or stack trace can make sense of. That sometimes means restating preconditions, sometimes pointing to boundary conditions, sometimes giving hints describing common causes of the exception - lots of different things that depend on the API, the activation context and the nature of the exception. The natural way to do this is to use natural language sentences. Please allow me to retain a straightforward way to construct these messages and to maintain the specificity and meaning of the messages. Phil > > > 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
