commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: svn commit: r960602 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/analysis/interpolation/ main/java/org/apache/commons/math/exception/ main/java/org/apache/commons/math/util/ main/resources/META-INF/localization/ site/xdoc/ tes...
Date Thu, 08 Jul 2010 11:43:51 GMT
> We are at a dead end here. The examples below were use cases I am
> interested in, at least from my point of view. We can probably stop this
> discussion here as you don't even acknowledge the efforts we do to find
> a consensus.

That's not true. And I'm at a complete loss because you don't seem to
understand my point, however I'm explaining it.
You say that you wish to reduce the number of messages/enums but it is
a fact no two of them contain exactly the same information, hence removing
one is, undoubtedly, a loss of information.

The (secondary) argument I was holding is that this loss is not significant
because the message (resulting from a precondition violation) is only
*temporary*: it appears because the program is not robust enough and the
its *real* purpose is to convey to the *developer* (through a bug report)
some hints as what happened and how to correct the problem. The message is
not there so that the user/operator can start to figure out how to work
around the problem. [I know that it could/will be used that way until
the next release but that's not the point.] The point is that in a library
like CM, the exceptions protect the library first (by not even
attempting meaningless computations) and, as a consequence, provide
robustness because the user (of CM) cannot avoid being informed of the

The primary argument is that in my opinion, the design error handling can be
improved. And, yes, that will make it simpler for developers. Is that bad?
Is that good for end-users? Perhaps they don't care right now (they won't
notice the difference). But if more developers are attracted to a
project because, among other things, it is based on a clear and simple
design, that will be good for end-users (more developers, more code, more
usefulness, ...)
I'm certainly not meaning that my proposal is that great, but it is an area
(however insignificant as compared to the sometimes complex math involved
in CM) where I could be of help.
IMO the (error handling) design is in a dead end. To elaborate on this
picture: We are approaching the dead end's wall but Phil and you want to go
on towards the wall without considering that the best place might be on the
other side of that wall, hence impossible to attain by this route.
Sometimes it is necessary to go back (i.e. loose features). What I proposed
is to emphasize good design and, from there, figure out how to fulfill the

If one of the requirements is to keep the exact same amount of information
as we have now in the list of 200+ messages, then I acknowledge that it is
in contradiction with my secondary argument. Let's say I drop it (that's
what I did already in my previous post).
Then we'll have to create a lot of exception classes; in principle, it's not
a problem. [I had just been attempting to avoid it (also because Phil said,
early on, that he didn't want this).]

> [...]

I've read all your comments. I'm happy that some of them were "Yes" but for
the rest it seems that we are playing an endless ping-pong game. Maybe it is
a limitation of the communication medium that makes it look like each of us
gives, to the other, the impression to be out of focus...

So I skip to here, where the same communication problem may be at work:

> > 
> > In order to try and satisfy everyone's requirements (without necessarily
> > reconciling them), I was thinking of introducing a second "Localizable"
> > instance variable in class "MathIllegalArgumentException". This one would
> > not be pattern but a more detailed explanation, that could also be
> > localized.  Hence the class
> >   "NumberOfPointsIsTooSmallException"
> > would inherit from
> >   "NumberIsTooSmallException"
> > and will display
> >   "number of points: argument (0) is less than 2"
> >    ^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >    Specific context       General problem
> Did you not recently suggest to follow the KISS principle ? This is not
> exactly a simple feature and it will completely ruin your previous
> attempt to simplify thing at the exception construction end.

Absolutely not; construction will be as usual:

  throw new NumberOfPointsIsTooSmallException(0, 2);

How much simpler could you expect it to be?

> I really don't understand how this suggestion match you first statement
> of replacing "number of points" with "arguments" because it was too
> complex. [...]

The simple solution is to drop the specific context but you don't want it.
So I'm proposing to add it back. Is it what you want, or are we still
playing ping-pong?

> Now you go to the complete opposite by adding a second message
> to get back the initial level of information, but with a far more
> complex solution.

More complex to implement but not to use (you'll just have to select the
exception class that suits your needs).

> > It will not reduce the global number of enums nor make the number of
> > exceptions small but it will at least have the advantage to separate the
> > general problem from the specific context where it occurred.
> > How does that sound?
> Clumsy.

If that's still your opinion, what alternative do you propose?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message