[...]
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").
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.]
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.]
If you actually have use cases for catching a specific exception, this
is a positive argument for implementing specific exceptions!
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).
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
