Hi, 2012/8/30 Gilles Sadowski <gil...@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-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
