Phil,
> > Do we have to obey every and all suggestions?
> > Taking the "community" argument for one-sided use is akin to a famous
> > joke on "communism".[1]
> >
> We need to *genuinely listen* - that means taking the feedback from
> the community into account as we develop the code. The reference
> below makes no sense to me (despite the fact that I can read
> French), unless it is directed at me personally, which I resent.
Oh, but *I* listen, if I did not, I couldn't have answered to the criticism
and suggestions expressed by the "community" in the thread you started.
To be (hopefully) perfectly clear: the one-sided listening I was referring
to is how much you argue about listening the others even if they don't
provide any backing for their opinion (which can be valid or not for CM),
while not taking into consideration any of the arguments I put forward,
especially not answering any of the constructive suggestions I propose or
telling why you don't agree with them.
What I resent is that you behave as if I were not one of those *users* that
you have most respect for.
> If
> it is a general comment on community-based development, it has no
> place here.
You are the one in the "community" who consistently ignores my direct
questions. You did it again above.
In the other thread, when I asked for clarification concerning the "map"
functionality, I obtained a thorough explanation also comprising an
acknowledgement that what exceptions we have could be retained. [But you
seem to have heard only the opposite claim.]
Then, I proposed incremental development, possibly leaving the
implementation of the "map" feature for a 3.1 release. No answer from
you.
> Phil
> >>> expressed a preference
> >>> for a "no hierarchy". We agreed on a singly rooted hierarchy (having
> >>> preferred it over reusing several Java standard exceptions as multiple
> >>> roots).
> >>> Nobody among the new parties to the discussion expressed anything
> >>> concerning
> >>> the specific problem of "FunctionEvaluationException".[1]
> >> I do not agree with the "consensus" to replace
> >> FunctionEvaluationException. It may end up one of the concepts we
> >> want to keep. As I have stated elsewhere, it cannot be replaced
> >> fully by MathUserException.
> > If you listen to some of the suggestions, it can:
> >
> > Solution (1):
> > throw new MathUserException("Failed to evaluate at " + x);
> >
> > Solution (2)
> > MathUserException e = new MathUserException("Failed to evaluate");
> > e.add("argument", x);
> > throw e;
> >
> > The points, made in the suggestions, were that specifc exceptions may not be
> > necessary, that a single exception with an English language message may be
> > sufficient.
> >
> > The point I make is that, if we consider squeezing the exception hierarchy
> > (a bad idea IMO), it would make even more sense to not have a dedicated
> > "FunctionEvaluationException". In such a context, there nothing inherently
> > wrong in reusing a "MathUserException" when some CM statement indeed "uses"
> > the "UnivariateRealFunction" interface (i.e. CM is a user of itself).
> >
> The point is that none of this is yet settled. I have consistently
> argued that, like ConvergenceException, FunctionEvaluationException
> may be an abstraction that it makes sense for us to keep. Just as
> it is natural and useful to report that a numerical algorithm has
> failed to converge, it is natural and useful to report (and be able
> to recover from) a failed function evaluation. In some (most?)
> cases, that failure will be associated with a user-defined function;
> in some cases not. Therefore, MathUserException cannot in my
> opinion fully *replace* FunctionEvaluationException (this is
> especially clear in the signature for UnivariateRealFunction#value)
>
> Once again, the point is that we have not settled any of this, so we
> should not make commitments to users in 2.1 that we may not keep in 3.0.
I have consistently made proposals to make the CM code more maintainable; I
have consistently posted issues about those proposals on JIRA; I have
consistently answered all arguments; I have consistently reported progress
on the work (deprecating exception, replacing them with the new ones);
sometimes after waiting a few days for a reply, I have consistently applied
the principle of "lazy consensus"; for *months* I've performed those changes
that you now seem so eager to revert, without letting a chance to the
current "design" (it's only a bunch of exceptions).
You behave like it is possible to achieve perfection in the 3.0 release of
CM. How can you compare CM (with its vast resource of still missing
algorithms) to another component of Apache Commons which can only be much
more focused?
No, the next major release of CM will not be perfect, even if is released in
ten years from now. So my opinion is that, in a community-based development,
it is not a crime to advance by trial and error. In fact, if it could be
done otherwise, then version 1.0 of CM would have been perfect already.
Maybe I'm completely off-base and the exceptions we have in "trunk" are
grossly inadequate and useless. So what? They will be removed in 4.0, along
with all the rest that will still not be right.
[Hmm, back to the most delightful (!) discussion subject: If recovering from
a failed evaluation made sense, then we should have a _checked_
"FunctionEvaluationException" but I'm sorry to tell you that such a
hypothetical recovery does not make any sense, not any more than a "null
pointer" or a divide by zero is recoverable. In the latter case, would you
tell that you recovered from zero-divide if you do not try to divide by
zero?
Of course, still talking without an actual use-case and you are probably
going to answer (maybe) that you don't understand that example, such as when
I tried to explain the difference in responsibilities between
application-layer exceptions and CM-defined exceptions.]
>
> Phil
> >>> The (new) issue of adding the "map" feature to the exceptions can be dealt
> >>> with as I proposed in a previous post.
> >>> Thus, unless I missed some points, I don't see anything that will change
> >>> with respect to what should be removed from 2.2.
> >>>
> >> Several people have pointed out that is may be a bad practice to
> >> lump exceptions into an exceptions package.
> > I've presented a few arguments in answer to that opinion; still waiting
> > counter-arguments (as in "Why is it a bad practice?"). [I know a few
> > drawbacks myself, but they are balanced by the advantages.]
> >
> > While I should abide by this pre-conceived statement (which might be
> > perfectly valid for some other "components", just not as clear-cut for
> > CM), isn't it strange that you don't "listen" to people who say that
> > message localization is a mistake?
> >
> >> Some of the
> >> deprecations are related to that.
> > Then make the deprecation less explicit concerning the location of the
> > replacements; that doesn't imply that the deprecations are not in order.
Here, yet another suggestion left lingering without counter-arguments.
In the hope that you have genuinely listened,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
