>
> +1 - here is an idea that can likely be improved:
>
> IllegalArgumentException - thrown when the activated method itself
> can ascertain that preconditions specified in the API expressed at
> the level of the activated method have been violated. In the vast
> majority of cases where [math] t
On 11/5/10 5:39 PM, Gilles Sadowski wrote:
Hello.
[...]
Of course, I didn't overlook that you just ask for a
@throws FunctionEvaluationException when the evaluation failed.
Javadoc comment.
I'm just reluctant to publicize a guideline that is not adhered to in CM!
Whenever a method is p
Hello.
> [...]
Of course, I didn't overlook that you just ask for a
@throws FunctionEvaluationException when the evaluation failed.
Javadoc comment.
I'm just reluctant to publicize a guideline that is not adhered to in CM!
Whenever a method is passed an argument that doesn't fulfill pre-condit
Hi Gilles,
- "Gilles Sadowski" a écrit :
> Luc,
>
> > > [...]
> > >
> > > There are at least 2 different issues:
> > > 1. What is the recommended behaviour of implementations
> > > 2. What CM will do when it calls "value" and catches an exception
> >
> > There is a third issue, and it was
Luc,
> > [...]
> >
> > There are at least 2 different issues:
> > 1. What is the recommended behaviour of implementations
> > 2. What CM will do when it calls "value" and catches an exception
>
> There is a third issue, and it was a driver for the current architecture.
> Some CM algorithms are u
Hi Gilles, and sorry for mistyping your name in my previous message,
- "Gilles Sadowski" a écrit :
> Hi.
>
> > > [...]
> > > >
> > > > What about new code? With the current signature and
> documentation
> > > > there is no information on possible exception conditions. The
> fact
> > > >
Hi.
> > [...]
> > >
> > > 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