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: [math] Re: Single root for Exceptions
Date Thu, 30 Aug 2012 10:02:32 GMT
Hi,

2012/8/30 Gilles Sadowski <gilles@harfang.homelinux.org>:
> On Wed, Aug 29, 2012 at 06:33:05PM -0700, Phil Steitz wrote:
>> On 8/29/12 3:04 PM, Gilles Sadowski wrote:
>> > 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
>> >  (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 - though I am OK advertising superclasses in cases where that is
>> appropriate (but not to the point of (3) below)
>> >  (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.
>> -1
>> In general, we should avoid that, because it is equivalent to
>> "throws Exception." The exceptions that a method in the public
>> [math] API propagates should be documented and advertised by it.
>> Which exceptions a method itself generates is an implementation
>> artifact.  What is important in the API is what exceptions the
>> caller is going to see.
>
> You are right. As I said, I was not sure that would be a good rule.
> [Also I don't think that there are many cases where exceptions are propagated
> from lower levels without being advertized in relation to the current
> context.]
>
> Thus, shall I open a JIRA ticket with the tasks of completing the "throws"
> clauses of all CM methods?
> Does someone absolutely needs this task tobe completed before releasing 3.1?
> [I don't think that it's possible without a huge effort from everyone.]
>

No hurry on my side, but I'm happy contributing. In order not to tread
on anyone's feet, maybe each of us should be assigned one package (for
a start).
S

>
> Regards,
> Gilles
>
>>
>> Phil
>> >
>> >
>> > 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.
>> >
>> >
>> > Regards,
>> > Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message