Le 30/08/2012 05:08, Sébastien Brisard a écrit :
> Hello,
>
> 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
>> (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, if only for the sake of the so-called "Luc's trick" (@Luc:
> something's called your name, that's the beginning of celebrity ;)
-1 to it being named Luc's trick :-(
> !!!).
>> (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.
Luc
>
> These are just a few thoughts from someone which is not experienced in
> this field...
>
> Sébastien
>
>
> ---------------------------------------------------------------------
> 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
