commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: svn commit: r1030464 [1/3] - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/ main/java/org/apache/commons/math/analysis/ main/java/org/apache/commons/math/analysis/integration/ main/java/org/apache/commons/math/analysis/inte
Date Fri, 05 Nov 2010 15:02:25 GMT
> >> So go ahead with the change, removing the throws from the declaration but keeping
the javadoc as suggested previously.
> >
> > Again, what is it that you try to convey by specifying a single exception in
> > the Javadoc? Any unchecked exception can be thrown from a class that
> > implement the interface.
> > If the user code doesn't care that the evaluation fails, it should catch
> > everything and continue. Alternatively, if it cannot continue, it should let
> > the exception propagate. In either case, there isn't any useful information
> > from a Javadoc "@throws" tag: We already know that unchecked exceptions can
> > arise.
> 
> Seems to me we should document any Exceptions that our code throws,
> along with the reasons for them.
> That way, the user can create specific catch clauses.

No disagreement about this principle.
But the "@throws" Javadoc comment should be placed where we _know_ that the
code throws the exception.
In "UnivariateRealFunction" it is impossible to know which exception is
thrown and which not.

> Also, the other RuntimeExceptions are generally unpredictable, whereas
> in this case, these Exceptions are only
> generated under specific circumstances.

Which exceptions?


Regards,
Gilles

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


Mime
View raw message