On Mon, 04 Nov 2013 20:48:34 +0100, Luc Maisonobe wrote:
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).
Of course, it can be done. Easy is not the same as good.
I'd have no problem to add those, if it'll make you happy to play with
the patterns in application code; but it should be marked as "internal"
and "subject to change without notice" (see below).
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.
This is just a false proposition!
All exceptions can be documented irrespective of being checked or
unchecked.
So the exact same argument holds
for both cases: user has to dig into the code (not documentation),
This is also false, in principle, since all exceptions which a call can
throw must be documented. If it is sometimes true in practice, it
counts
as a bug (of the 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).
Breaking the contract is breaking the contract; compile- vs run-time
has
nothing to do with it.
What I say is that the developers should be _allowed_ to change
anything
that pertains to internal utilities without notice.
The localization utilities are internal, the exception types are not.
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.
No, that is not my argument: It is rather that users must not rely on
internals. And that we should not advertize internals, and that we
should
explicitly warn users to not use internal code (or use it with the
knowledge
that it can change, and that they will have to modify their code
accordingly
at any new release).
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 [...]
[See above.]
and its a lot of work to change.
But it can be done incrementally.
It is a pity that we have to argue to no end since; you agree that is
cleaner, but it changes nothing. Each time a newcomer asks a question
that
touches on some unfinished job, we restart the discussions at the exact
same point (and sometimes even backwards from what was agreed before).
Gilles
> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
