Le 03/03/2011 23:51, Gilles Sadowski a écrit : > Hi. > >>>> 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. > > The class "CorrelatedRandomVectorGenerator" does not use the > "CholeskyDecomposition" from package "linear"; it has its own "decompose" > method which explicitly throws "NonPositiveDefiniteMatrixException" > instances (at lines 214 and 222).
Right. I did not remember that (despite I wrote this code). > >>> 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. > > I propose to extend the "MathThrowable" interface with methods declarations > similar to what is done in [Lang] and implement the functionality in > "MathRuntimeException". [While looking at it, I notice that [Lang] has > a dedicated "exception" package...] Fine. > >>> >>>>> >>>>>> 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 ? > > But why would one prefer to write > --- > throw MathRuntimeException.createNullPointerException(); > --- > instead of > --- > throw new NullPointerException(); > --- > ? For example to have a single point where to put breakpoints for debugging. I used that a lot as such exceptions mainly occur during development phase. > > Not only is this inconvenient, it is also dangerous: I was bitten more than > once writing this: > --- > MathRuntimeException.createNullPointerException(); > --- > which the compiler happily accepted. Of course, as it would have accepted: new NullPointerException(); Unfortunately, we cannot put the throw inside the method. Trying to do this prevent the optimizer to wor properly as it does not know in the caller that the method would never return, and it brings lots of warnings from code checking tools for the same reason. Luc > >>> >>>>>> 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. > > Indeed, indeed... > > > Best regards, > 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
