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-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
