Le 04/11/2013 19:49, Gilles a écrit : >>>>> [...] >>> >>> 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>). > > There is a bit of confusion here; the ExceptionContextProider was part of > the initial batch of features: > https://issues.apache.org/jira/browse/MATH-566 > What you added a few months later (not in 2001 :-) was a method > Exception getException() > to the "ExceptionContextProvider" interface. > > And by the same token as you used above, this could count as a "failure" > too since it is used only once in the code > ("o.a.c.m.ode.events.EventState").
You are right. It is public and I use it outside [math]. > > I remind that the "setValue" feature was primarily intended for _user_ code > (and suggested in a discussion, with the broader Commons community, as a > service to users). [I was pretty sure at the time already that it wouldn't > have much use inside CM.] Thanks for the reminding, I was not aware of it and thought it was intended so we supplement our exceptions when we throw them. I personaly have no use case about adding up something to an exception that was already thrown, but understand someone else may have such cases. I only have cases when I want to retrieve information from exception, as I consider them immutable _once they have been thrown_ (which is simply due to my own limitation). > > Moreover, the sole uses would probably be superseded by logging statements > if the possibility existed in CM. This is really a pure annoyance[1] for a > library that purports to be used in scientific applications, where one > sometimes needs to recover how an algorithm arrived to a solution (e.g. in > order to assess whether the chosen algorithm is appropriate for the problem > at hand). > >> >> 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. > > IMO, this is a very bad (TM) idea since it assumes that a given pattern > is here to stay forever. [Whereas it surely counts as "unstable" or > "implementation detail", not to be counted on more than the value > returned by the "toString" method.] I agree, but it is already present and needs almost no work (except adding one or two methods in the single ExceptionContext class). > > If you actually have use cases for catching a specific exception, this > is a positive argument for implementing specific exceptions! Yes from a theroetical point of view but we already know it does not work in practice as we cannot document properly what is thrown since we have switched to unchecked exception. So the exact same argument holds for both cases: user has to dig into the code (not documentation), and code changes can break this anytime without the user noticing it (we can change the pattern, and we can change the exception type, user code will still compile and run ... until it randomly breaks at runtime). So both methods have the same advantages, both methods have the same drawbacks, and one method implies lot of works. > It is beyond me that you can argue to use unspecific instances of > "MathIllegalArgumentException" and then add code that digs into the > internals of those. > Java enables one to catch specific exception types[2]; our job is to > provide those types (i.e. define more exception types, not less). > Everything points to the same direction, except perhaps old habits > (old, but by no means standard). It is beyond me that you can argue to change code that runs and may fail sometimes by other code that will runs and may fail for the exact same reasons, without adding any new security. Changing code only for the sake of changing code (and satisfying only theoretical peace of mind) mainly introduces new bugs. Hey, don't take the previous paragraph too seriously, I was only kidding there! I agree accurate exception types are cleaner. What I say is simply they are *not* safer and its a lot of work to change. Luc > >> I have no real idea about improving the currently almost >> unused key/value feature, but fear it would imply a tremendous work > > From an internal POV, my opinion is that it can be removed. > I don't know what you mean by improving here. The feature is there, and > can be used. [But we can decide that we don't want to maintain a tool > which nobody sees how it can be useful inside CM, and which nobody uses > outside CM.] > >>> >>>> 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. > > Yes, it's a repetitive work (a "grep" for each pattern and see whether the > same information can be composed from the "little blocks"). > That's why I mentioned it among the consistency "tasks" inquired about by > Sean. > > > Best regards, > Gilles > > [1] Several times, I found myself obliged to use an ad-hoc version of CM > (containing tediously added "print" statements) in order to trace the > behaviour of the optimizers. > [2] With added features in Java 7. > > >> > > [...] > > > --------------------------------------------------------------------- > 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
