Hi Luc, Thanks for repeating that you agree with most points, as was the case with all the changes I had been implementing in "trunk". The discussion went awry when, because of a single point of disagreement (about whether a user-only "FunctionEvaluationException" should be defined in CM), all the work on the exception revamping of these past 6 months has been threatened of nullification based on matters of taste.
Below, I've heavily cut the quoted parts of the thread because it has become fairly difficult to distinguish the new information. > >> It is a requirement for many libraries. In fact I even saw this > >> requirement being explicitly written in the specifications of an > >> official public Request For Proposal for a project concerning Apache > >> Commons Math. > > > > Out of curiosity, where can I read that "Request For Proposal"? > > Sorry, you cannot read it. It's access is restricted to the company who > were previously selected in a frame contract. It's for a public agency, > were we met a few months ago (but not for the same people). I was asking because you said: "[...] public Request For Proposal [...]". > > > >> 3) don't put all exceptions in a dedicated exception package > >> (but the general exceptions used everywhere could go there) > > > > -0 because most exceptions are general and thus I don't see the benefit of > > scattering the remaining few among several packages. > > > >> 4) put specific exceptions in the package they are triggered > >> (for example ODE, linear ...) > > > > -1 unless we can be convinced that the specific exception has no usage in > > another package (now and in the foreseeable future). > > SingularMatrixException, NonSymmetricMatrixException and the likes are > really tightly bound to linear algebra and could be in the linear > package where they are triggered. They could appear in the signatures of > algorithms in other package that do call linear algebra, but this is not > sufficient to put them in a general package. Yes, the "...MatrixException" classes are the borderline case (meaning that, if they were the majority of exception classes, I'd prefer to see them in the "linear" package). However, I argue that when there exists an "exception" to contain the general exceptions, then it is clearer to have them all there. Moreover "NonPositiveDefiniteMatrixException" is already a counter-example as it is used in "linear" and in "random". Since we probably won't have much more exception classes than there are now (31 out of which less than 10 are probably candidates for relocation in their main use package), it is fairly manageable and it will be more stable. > > > >> 5) use a small hierarchy backed by an implementation of the principle > >> of exception context as per [lang] to provide state information > >> and allow extension by users calling addValue(label, value), > >> a typical example could be one ConvergenceException class and > >> different labels/values for count exceeded or NaN/Infinity appearing > > > > -1 for removing any of the new exceptions (except "NullArgumentException"): > > The hierarchy in trunk is shallow and small. > > > > +0 for implementing the map feature. > > Do you mean it as replacement of the "general" and "specific" message > > pattern (i.e. CM would use this feature) or as a user-only feature? > > I was thinking at both replacing the general and specific features and > letting users call it in case they want to add their own stuff. I'll create a JIRA issue for the new "map" feature, to discuss the details of the functionality. > > > >> 6) don't provide any top-level exception for errors occurring in > >> user-provided code (for solvers, ode, matrix visitors ...) but > >> ask them in documentation to use their own unchecked exception > >> that [math] will never see (i.e. remove FunctionEvaluationException, > >> DerivativeException, MatrixVisitorException) > > > > +1 for removing all exceptions for which there doesn't exist any "throw" > > statement within CM. And also "MathUserException" (the few uses of it in > > trunk should be replaced). > > > >> I'm not sure for NullPointer/NullArgument. Perhaps our own > >> NullArgumentException with the [lang] exception context principle would > >> be fine. I doubt we should check everything by ourselves (it would be a > >> real performance killer), so whatever we choose there will be untracked > >> NPE. We should check some arguments where it makes sense, which is what > >> we already do at some places. > > > > +1 for dropping "NullArgumentException" and letting the JVM raise NPE. I'll also create a JIRA issue for reaching a conclusion on this one. > >> Hoping to conclude this fast ... > > > > Let's not be too hasty ;-). There can be some work left for 4.0. > > I hope this would be algorithm work. New algorithms can always be included in 3.x releases. I was referring to a "refactoring" (which entails incompatibilities). This is not a bad thing; quite the contrary, this is how a programming project stays alive, in sync with technology advances, and keeps attracting developers. Best, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
