commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From S├ębastien Brisard <sebastien.bris...@m4x.org>
Subject Re: svn commit: r1383770 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math3/exception/util/ main/java/org/apache/commons/math3/linear/ main/resources/assets/org/apache/commons/math3/exception/util/ test/java/org/apache/commons/ma
Date Wed, 12 Sep 2012 12:20:34 GMT
>> >>              } 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 &divide; a.
>> >      * @param a element to add
>> >      * @return a new element representing this &divide; 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message