commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Neidhart <thomas.neidh...@gmail.com>
Subject Re: [math] Re: Single root for Exceptions
Date Thu, 30 Aug 2012 18:07:22 GMT
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 <gilles@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message