> > > > Please discard my previous message... > > Again one disability of mine (apart from not being an HTML parser): I > > process messages sequentially. :-) Sorry. > > > As for me, I can't read emails (you pointed at INDEX in one of your > previous messages...).
So we are even. ;-) > > > > > But, there was something else: > > > >> > >> Modified: > >> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/ArrayFieldVector.java > >> URL: > >> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/ArrayFieldVector.java?rev=1383770&r1=1383769&r2=1383770&view=diff > >> ============================================================================== > >> --- > >> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/ArrayFieldVector.java > >> (original) > >> +++ > >> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/ArrayFieldVector.java > >> Wed Sep 12 04:43:38 2012 > >> @@ -560,7 +560,7 @@ public class ArrayFieldVector<T extends > >> try { > >> out[i] = one.divide(data[i]); > >> } catch (final MathArithmeticException e) { > >> - throw new MathArithmeticException(LocalizedFormats.ENTRY, > >> i); > >> + throw new MathArithmeticException(LocalizedFormats.INDEX, > >> i); > >> } > >> } > > > > Do we really want to do this instead of checking a precondition (or do > > nothin at that level)? I know that it would be preferrable to (also) report > > the INDEX, but on the other hand, this kind of code becomes really ugly (in > > the sense that there are more signs related to failure detection and > > handling than to the "interesting stuff". > > > I agree that it is ugly. I would like to know what others think. I'm > perfectly happy propagating a MathArithmeticException which does not > report on the index. If more messages is always is better, we might have to get used to this kind of construct... > > > Moreover, you can an exception and completely discard the information it > > might have contained! [In this case, the info might likely have been > > "division by zero".] ... but the original message(s) should definitely be kept: try { out[i] = one.divide(data[i]); } catch (MathArithmeticException e) { e.getContext().addMessage(LocalizedFormats.ENTRY, i); throw e; } > > > > Finally a more general point: In the "FieldElement" interface, there is > > --- > > /** Compute this ÷ a. > > * @param a element to add > > * @return a new element representing this ÷ a > > * @throws NullArgumentException if {@code a} is {@code null}. > > * @throws MathArithmeticException if {@code a} is zero > > */ > > T divide(T a) throws NullArgumentException, MathArithmeticException; > > --- > > > > This is another example of what I pointed to a few days ago: Documenting > > MathArithmeticException is wrong because not all implementations behave that > > way (e.g. "Complex"). [Alternatively, it can be construed that "Complex" is > > not correctly implemented (cf. MATH-667).] > > > > [There is also a typo in the description of param "a".] > > > > Best regards, > > Gilles > > > For what it's worth, Decimal64 does not throw an exception either. So > maybe MathArithmeticException should be removed from the signature of > FieldElement.divide(), as it's clearly not part of the contract of > this method. No runtime exception can be part of an enforceable contract. We should not advertize that _interface_ methods throw exceptions; only exceptions that can actually be thrown should be documented. > However, some fields do not know NaN, and it would be nice to have a > guidance in the javadoc of the interface, regarding what exception > should be thrown. Various use-cases could be mentioned. Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
