> >> IMHO we still need the @throws line in the javadoc. Otherwise end > >> users are going to get a nasty surprise when they get an unchecked > >> exception thrown. > >> > > > > Any existing user code (throwing a "FunctionEvaluationException" at some > > point and catching it at another) will still work the same as before > > (provided they change the "import" statement). No surprise to be expected. > > > > > > Best, > > Gilles > > > > What about new code? With the current signature and documentation > there is no information on possible exception conditions. The fact > the method will throw an exception on failure needs to be expressed. > > [...]
The fact is: You don't know whether an exception will be raised on failure. It depends on the implementation: A user might decide that failure is dealt with by returning "NaN" (or Infinity). Another user might decide to throw a "MathIllegalArgumentException" or a subclass thereof or something completely different... :-) IMHO, the "FunctionEvaluationException" is fairly useless. Its only use I can see is to wrap "alien" (user-defined) exceptions: Any methods in CM could call "value" within a try/catch block, catch any "RuntimeException" and rethrow it wrapped inside our own "FunctionEvaluationException" such that it can always print a localized message. [Note that in this case, it is not the "value" method that throws "FunctionEvaluationException" but the code that calls "value".] Best, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
