Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of phil.steitz@gmail.com
 designates 209.85.210.43 as permitted sender)
Message-ID: <503EC2D1.5010604@gmail.com>
Date: Wed, 29 Aug 2012 18:33:05 -0700
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [math] Re: Single root for Exceptions
References: <50367DE8.20909@gmail.com>
 <20120823233544.GS24856@dusk.harfang.homelinux.org>
 <50372DDD.2050003@free.fr>
 <20120825214353.GU24856@dusk.harfang.homelinux.org>
 <5039CE39.2030705@free.fr> <503A5FF8.1030408@gmail.com>
 <503CBB41.7050005@free.fr> <503D2C04.40507@gmail.com>
 <20120828234049.GC24856@dusk.harfang.homelinux.org>
 <503DCC91.8010103@free.fr>
 <20120829220454.GG24856@dusk.harfang.homelinux.org>
In-Reply-To: <20120829220454.GG24856@dusk.harfang.homelinux.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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.  

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