commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From S├ębastien Brisard <>
Subject Re: [math] Re: Single root for Exceptions
Date Thu, 30 Aug 2012 03:08:28 GMT

2012/8/30 Gilles Sadowski <>:
> 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.
>  (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, if only for the sake of the so-called "Luc's trick" (@Luc:
something's called your name, that's the beginning of celebrity ;)
>  (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

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

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.

These are just a few thoughts from someone which is not experienced in
this field...


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message