>> >> } 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;
> }
>
Good idea. I wasn't aware of this possibility until your previous
message. Thanks for the tip!
>> >
>> > 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.
>
OK, I'll go back to some changes I've done for the sake of MATH-854,
then. I thought that exceptions which *were* thrown by any
implementation ought to be advertised in the interface.
What I liked in this way of doing things is that people who want to
implement a given interface can do so consistently, even in the case
of exceptional situations. They do not have to think "hmmm, what
exception should I throw in this specific case?".
What I'll do instead is remove all throws clauses, and add Javadoc
comments like "implementations should throw a XxxException when
[...]". How does that sound?
>
>> 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.
>
... Will do that in the Javadoc (see my comment above).
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
