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 Wed, 07 Jul 2010 14:47:39 GMT
> > Then perhaps you missed some of the comments here above, and also at
> >
> > and/or at
> >
> > and references therein (Bloch, Goetz).
> > 
> > Or perhaps we (Eckel et al.) are all wrong. In this case, please show me
> > modern, high-profile, Java library projects that deal with exceptions in
> > the same way that you want it for CM.
> > 
> What is important and relevant to discussion here is how we
> structure and manage exceptions in [math].  It is best for us to
> keep the discussion focused on concrete examples, with arguments
> supported directly using [math] use cases.

I'm proposing a revision of the exception design structure (or lack thereof)
that is supported by those references, and you say that they are not
relevant. I cannot argue with that.

>  Luc and I have provided
> examples of use cases where the changes that you are proposing are
> not optimal for users.  You need to respond directly to these examples.

You have a number of use cases equal to 1. Of course, the current design
makes it impossible to implement the use cases which I presented (cf. the
initial mail about "Localization and error handling", the comments on JIRA,
and on this ML). Because of this you could say that I have 0 use case; so...
You win :-!

> The specific change that we are talking about here is the
> replacement of an IllegalArgumentException with an error message
> containing context information about what argument was "illegal" and
> why by a "NumberTooLargeException" containing no reference to the
> argument.  I have two problems with this change:
> 1. There is loss of failure-capture information (i.e., the specific
> argument that was out of range)
> 2. I don't see the value in this abstraction.  We all agree that we
> need to add more structure to our exceptions hierarchy.  I may well
> be missing something here, but I don't see what this particular
> abstraction buys us and in particular why it is the appropriate
> abstraction for the context in which it is thrown above.
> Can you respond directly to these issues, please?

Strictly speaking you are right, replacing "number of points" by "argument"
looses information. However, I think that a user with only the error message
created by CM will be as lost with your message as with mine. My point is
that a precondition violation message is almost always useless if there is
no stack trace to recover the root of the problem. Your order of importance
of information bits is definitely not the same as mine.
[But see at the end of my other reply to this thread, where I try to address
your concerns, while you still didn't address mine.]


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

View raw message