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: [math] UnexpectedNegativeIntegerException
Date Fri, 24 Aug 2012 14:09:34 GMT
Hello S├ębastien.

> >
> > > > [...]
> > >
> > > I see that's another area where everyone has its own opinion because
> > > of various experiences. I was previously in favor of exceptions, but
> > > maybe it's too much for such a low-level component as a standard or
> > > special function. So I am now convinced that NaN should be returned by
> > > Gamma in case of invalid values. However, in the class Gamma, there
> > > are other very low-level functions, which provide some approximations
> > > of say Gamma(1 + x) - 1, *only in a specific range*. I believe that in
> > > that case, an exception should be returned, as the function itself is
> > > defined mathematically, it's only the approximation which is not
> > > valid.
> >
> > I'm not so sure that an exception must be thrown. Of course the doc should
> > say that the approximation is not valid beyond the specified range, but,
> > since the function is defined, a user could be interested in experimenting
> > with what happens beyond the limits.
> >
> 
> I'm not a big fan of that, but I can live with it. Instead of
> exceptions, I'll place some assertions. Do you like it better?

No. We didn't agree that "assert" statements can be included in CM code.

[Personally, I don't think that it's a good idea that low-level utilities
behave differently (with or without assertion enabled) when given the same
inputs.]

Please just use exceptions, to provide less forgiving but more robust code.
We can see later whether it makes sense to relax the access to the
"dangerous" code...


Best,
Gilles

> I actually think it's a good compromise, since it allows a little bit
> of debugging (provided assertions are enabled).
> 
> >
> > > NaN would be documented in the Javadoc. And since we are talking about
> > > consistency, maybe it's better to be consistent with standard
> > > functions, which do not raise exceptions but return NaNs instead.
> >
> > Maybe, but this only states that we want consistency with "something" (in
> > this case, the behaviour of the functions of the standard Java Math class).
> > It doesn't say why it is useful to return NaNs.
> >
> > We have thus a case where consistency is deemed good for its own sake. The
> > same should hold for the code formatting issue.
> >
> >
> > Regards,
> > Gilles
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> S├ębastien
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 

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


Mime
View raw message