commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [MATH] Interest in large patches for small cleanup / performance changes?
Date Mon, 04 Nov 2013 18:49:53 GMT
>>>> [...]
>>
>> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message