Hi Phil,
thanks for this answer.
2012/9/13 Phil Steitz <phil.ste...@gmail.com>:
> On 9/12/12 11:27 PM, Sébastien Brisard wrote:
>> Dear all,
>> in previous discussions, it was decided that Interfaces (and, I
>> suppose abstract methods) should *not* have a throws clause.
>
> I probably should have responded earlier that I personally disagree
> with that conclusion. What is advertised in the interface may be a
> superclass of what an implementation throws; but if it makes sense
> as part of the API contract, it should be advertised by the
> interface or abstract method.
>
I agree with your point of view. It turns out that I misunderstood.
I will revert the changes done on FieldVector.
Sébastien
>
> Phil
>> So, yesterday, I started modifying the javadoc of FieldVector. Each
>> "throws" clause was simply replaced by the following statement
>> "Implementations should throw [...] if [...]". Please have a look to
>> FieldVector and ArrayFieldVector for clarity.
>> This has several drawbacks
>>
>> 1. The javadoc of implementations must grow, since the implementer
>> must write something like
>>
>> /**
>> * {@inheritDoc}
>> *
>> * @throws DimensionMismatchException if {@code v} is not the same size
>> as
>> * {@code this}.
>> */
>>
>> instead of simply writing /** {@inheritDoc} */.
>>
>> 2. The resulting javadoc of implementations is not satisfactory. For
>> example, the javadoc of FieldVector<T>.add(FieldVecto<T> v) now reads
>>
>> // Begin Javadoc
>> Compute the sum of this and v. Implementations should throw
>> DimensionMismatchException if v is not the same size as this.
>>
>> Specified by:
>> add in interface FieldVector<T extends FieldElement<T>>
>> Parameters:
>> v - vector to be added
>> Returns:
>> this + v
>> Throws:
>> DimensionMismatchException - if v is not the same size as this.
>> // End javadoc
>>
>> The "should throw" statement should really not be here, but it is too
>> much of a hassle to rewrite the whole javadoc comment for each
>> implementation.
>>
>> 3. Using Luc's trick brings a whole lot of error messages
>>
>> // Begin error message
>> Exception MathXxxException is not compatible with throws clause in [...]
>> // End error message
>>
>> this is not really a problem, but it makes the whole process of
>> populating the throws clauses a bit difficult.
>>
>> 4. More importantly, there is *no way* to ensure that we actually
>> document all exceptions. Indeed, if we take for example
>> FieldVector<T>.mapDivide(T d)
>>
>> The only reason we know we *have* to add MathArithmeticException to
>> the throws clause is because FieldElement (which is an interface)
>> *specifies* this exception in the throws clause of
>> FieldElement<T>.divide(<T>).
>> If this throws clause is removed from interfaces, then LUC'S TRICK
>> becomes useless. [1]
>>
>> For all these reasons, I would advocate *specifying* in interfaces
>> exceptions which we know must occur. For example,
>> DimensionMismatchException will be in the signature of *all*
>> implementations of FieldVector.add(FieldVector). Why not add it to the
>> throws clause? The answer is likely to be "because it is bad
>> practice", but I think advertising unchecked exceptions is already a
>> bad practice. So I think if we go for a bad practice anyway, we should
>> do it *only if it makes our lives easier*. I don't think the current
>> state does.
>>
>> On a more personal side, I'd like to say that I'm getting tired of
>> this issue. I have been working for days on the linear package, but
>> I'm making no progress, because each time I commit a change, I realize
>> this was not the proper thing to do because of new exchanges on the
>> ML. So I keep going back and forth. This is really sucking all of my
>> C-M time, while I'd like to be working on other issues (eg special
>> functions Gamma and Beta, visitors for FieldVectors, ...). That would
>> be perfectly fine if I could see the benefit of MATH-854. While this
>> seemed a good idea when we started discussing it, I'm not sure
>> anymore, now that we have really tried to implement MATH-854.
>>
>> I'm sure that I'm not the only one among the regular developers to
>> spend so much time on this issue. Our powers are limited, and I really
>> would rather we had more time to concentrate on real (meaning,
>> numerical) issues.
>>
>> Sébastien
>>
>> [1] MathArithmeticException in FieldElement.divide(FieldElement) is
>> probably not the best example, as Gilles noted inconsistencies
>> (Decimal64 and Complex do not throw an exception, but return NaN
>> instead).
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
