On 08/30/2012 12:41 PM, Luc Maisonobe wrote:
> Le 30/08/2012 05:08, Sébastien Brisard a écrit :
>> Hello,
Hi,
sorry, I did not participate much in the discussion.
>> 2012/8/30 Gilles Sadowski <gil...@harfang.homelinux.org>:
>>> Hello.
>>>
>>> To summarize:
>>> (1) Does anyone disagree with having all CM exceptions inherit
>>> from a new "MathRuntimeException" which itself will inherit
>>> from the standard "RuntimeException"?
>> +0: my background is not good enough.
>
> +1
+0
>>> (2) Does anyone disagree with all exceptions being mandatorily
>>> advertized in the "throws" clause of methods and constructors?
>>> That means that for each exception explicitly instantiated in the
>>> body of the method, the instantiated type must appear in "throws"
>>> clause.
>
> +1
+1
>>> (3) Does anyone disagree that the "throws" clause of a method could
>>> advertize "MathRuntimeException" for any exception not thrown by
>>> itself but by a method which it calls?
>>> That means that it is not mandatory to indicate the specific type
>>> for exceptions not explicitly instantiated in the body the current
>>> method.
>>>
>>>
>>> I'm not sure about point (3); it seems that it would avoid duplicating
>>> descriptions of lower-level preconditions for CM methods that calls other CM
>>> methods or advertizing something that would be an implementation detail for
>>> the calling method. I didn't check how often that would apply...
>>> At first sight, that would surely avoid that upper levels are tightly
>>> coupled to lower levels: if a method is modified to throw a new exception,
>>> methods that call it do not have to update their documentation and "throws"
>>> clause.
>>>
>> -0: I don't like the idea of advertising such a general exception, but
>> again, I lack the general background in computer science. Maybe we
>> could ask ourselves two questions
>> 1. If, when changing the implementation of a method, it turns out that
>> an exception is no longer thrown, or a new one is thrown, does this
>> break compatibility?
>> 2. Surely, there are two cases about exceptions thrown by a method
>> called within the method under consideration.
>> 2a. If the exception is raised by a method called by an object the
>> end-user knows, e.g
>>
>> public ReturnType theMethod(final ParamType x) {
>> // I am going to throw an exception
>> theOtherMethod(x);
>> }
>>
>> in this case, the exception might still be meaningful to the end user
>>
>> 2b. if the exception is raised by a method called with an object the
>> end-user doesn't know
>>
>> public ReturnType theMethod(final ParamType x) {
>>
>> final AnotherType y = ...
>> // I am going to throw an exception
>> theOtherMethod(y);
>> }
>>
>> in this case, the exception might not be so meaningful, and maybe
>> advertising MRE would be sufficient (although I still do not really
>> like that).
>>
>> Cases 2a and 2b might well be not so clear cut. E. g. what do we do
>> with method calls like theOtherMethod(x, y)? So I would be slightly in
>> favor of precisely advertizing every single exception.
>
> I think we must advertise them, as long as they are thrown by [maht]
> itself. Either we do the work all the way through or we don't do it.
> Stopping at the first level of public API would be wasting our time
> without benefits. Exceptions do propagate, if we need to know they are
> thrown, we need it all the way through. If we decide its too much work,
> then we should not bother doing it even on first call level.
I agree here with the comment of Luc, either we do it full-way or leave
it as it is now.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
