Le 03/03/2011 16:34, Gilles Sadowski a écrit : > 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".
It is used in random because the classes in the random package do use the linear package to perform a Cholesky decomposition, which triggers the exception. This is an example of the last sentence in my rationale above. This appearance is not sufficient to put the exception out of linear. > > 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. Let's wait for the opinions of other people and decide upon that. > >>> >>>> 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. Fine, but discussion is easier on the list (with a dedicated thread), we can open the Jira issue once we have decided what to do. > >>> >>>> 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. OK, I think we agree here. Phil preferred the way we created runtime exceptions as of 2.1, though. Perhaps we could revive a simple createNullPointerException without arguments ? > >>>> 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. Yes, but lengthy and harsh discussions keep them away. Luc > > > Best, > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
