Le 21/11/2010 00:08, Gilles Sadowski a écrit :
>> +++
>> commons/proper/math/trunk/src/main/java/org/apache/commons/math/linear/AbstractRealVector.java
>> Sat Nov 20 21:01:50 2010
>> @@ -20,9 +20,9 @@ package org.apache.commons.math.linear;
>> import java.util.Iterator;
>> import java.util.NoSuchElementException;
>>
>> -import org.apache.commons.math.exception.FunctionEvaluationException;
>> import org.apache.commons.math.exception.MathUnsupportedOperationException;
>> import org.apache.commons.math.exception.DimensionMismatchException;
>> +import org.apache.commons.math.exception.MathUserException;
>> import org.apache.commons.math.exception.OutOfRangeException;
>> import org.apache.commons.math.analysis.BinaryFunction;
>> import org.apache.commons.math.analysis.ComposableFunction;
>> @@ -156,11 +156,7 @@ public abstract class AbstractRealVector
>> /** {...@inheritdoc} */
>> public RealVector mapAddToSelf(double d) {
>> if (d != 0) {
>> - try {
>> - return mapToSelf(BinaryFunction.ADD.fix1stArgument(d));
>> - } catch (FunctionEvaluationException e) {
>> - throw new IllegalArgumentException(e);
>> - }
>> + return mapToSelf(BinaryFunction.ADD.fix1stArgument(d));
>> }
>> return this;
>> }
>> @@ -356,7 +352,7 @@ public abstract class AbstractRealVector
>> public RealVector mapAbsToSelf() {
>> try {
>> return mapToSelf(ComposableFunction.ABS);
>> - } catch (FunctionEvaluationException e) {
>> + } catch (MathUserException e) {
>> throw new IllegalArgumentException(e);
>> }
>> }
>
> This is in contravention of the stated policy of not catching
> "MathUserException" in CM code.
Yes, some of these errors crept in with the refactoring.
In fact, in order to make sure no javadoc was missing (which was our
decided convention), I temporarily make MathUserException extend
MathException, then fixed throws clause errors and javadoc, then removed
the hack on MathUserException. I found it was far easier to do this and
make sure nothing was forgotten than relying only on code reading.
> Moreover, it is useless since the ABS function will never throw such an
> exception. In fact, I think that none of these functions throws any
> exception; the "try/catch" should be removed entirely.
You are right. Could you remove them, I will be away all day ?
thanks for reviewing this
Luc
>
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
