Hi Gill, ----- "Gilles Sadowski" <gil...@harfang.homelinux.org> a écrit :
> > >> 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 When this exception was unchecked, it was the primary use of it : wrapping exceptions unknown to [math]. Of course, we cannot enforce users to use it and even when it was checked users could decide to throw any other unchecked exceptions or return NaN. Documenting it is simply a gentle way to tell our users this exception is the recommended way to signal errors. best regards, Luc > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
