You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Sébastien Brisard <se...@m4x.org> on 2012/09/01 09:27:50 UTC
Re: [math] Re: Single root for Exceptions
Hello,
2012/8/31 Thomas Neidhart <th...@gmail.com>:
> On 08/31/2012 11:17 AM, Luc Maisonobe wrote:
>> Le 31/08/2012 03:22, Sébastien Brisard a écrit :
>>> Hello,
>>>
>>>>>>> [...]
>>>>>>>
>>>>>>> Thus, shall I open a JIRA ticket with the tasks of completing the "throws"
>>>>>>> clauses of all CM methods?
>>>>>>> Does someone absolutely needs this task tobe completed before releasing 3.1?
>>>>>>> [I don't think that it's possible without a huge effort from everyone.]
>>>>>
>>>>> Ticket created:
>>>>> https://issues.apache.org/jira/browse/MATH-854
>>>>>
>>>>>>>
>>>>>>
>>>>>> No hurry on my side, but I'm happy contributing. In order not to tread
>>>>>> on anyone's feet, maybe each of us should be assigned one package (for
>>>>>> a start).
>>>>>
>>>>> Good idea.
>>>>>
>>>>> Gilles: packages "o.a.c.m.optimization"
>>>>> "o.a.c.m.analysis.function"
>>>>> "o.a.c.m.analysis.solvers"
>>>>> "o.a.c.m.analysis.integration"
>>>>> "o.a.c.m.analysis.interpolation"
>>>>
>>>> +1 to divide and conquer. I will start on stat.
>>>>
>>>> Phil
>>>>>
>>>>>
>>>>> Best regards,
>>>>> Gilles
>>>>>
>>> I can take care of linear and special, of course!
>>
>> I'll look at ode, differentiation and geometry.
>
> I will start with filter and genetics.
>
> Thomas
>
Just to make sure I don't forget anything... We must apply
you-know-who's trick to 4 and only 4 exception types
- MathArithmeticException
- MathIllegalArgumentException
- MathIllegalStateException
- MathUnsupportedOperationException
Is that correct?
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Re: Single root for Exceptions
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello.
> >
> >> >>>
> >> >>> in ConjugateGradient, I get the following error
> >> >>>
> >> >>> "Exception NonPositiveDefiniteOperatorException is not compatible with
> >> >>> throws clause in
> >> >>> PreconditionedIterativeLinearSolver.solveInPlace(RealLinearOperator,
> >> >>> RealLinearOperator, RealVector, RealVector)"
> >> >>>
> >> >>> This comes from the fact that general iterative solvers do not require
> >> >>> positive definite operators (therefore, no
> >> >>> "throws NonPositiveDefiniteOperatorException" clause in the signature of
> >> >>> PreconditionedIterativeLinearSolver.solveInPlace), while conjugate
> >> >>> gradient does.
> >> >>>
> >> >>> Do I need to add the "throws NonPositiveDefiniteOperatorException"
> >> >>> clause in the signature of
> >> >>> PreconditionedIterativeLinearSolver.solveInPlace as well?
> >> >>
> >> >> I think so, as users may use a ConjugateGradient and store it in a
> >> >> variable declared with the base class only. However, I don't know if
> >> >> adding an unchecked exception to the signature of an interface is a
> >> >> compatible change or not.
> >> >>
> >> >> Luc
> >> >>
> >> > clirr does not seem to be complaining, so I'll do as you say. Here is
> >> > what I'm planning to add to the javadoc of the mother abstract class.
> >> > What do you think?
> >> >
> >> > * @throws NonPositiveDefiniteOperatorException if {@code a} or {@code m}
> >> > * is not positive definite (required by some iterative solvers)
> >>
> >> Perfect!
> >
> > I don't agree on the principle that base classes/interfaces should be aware
> > of the detailed requirements of their implementations.
> > We can foresee that subclasses might need to throw _some_ kind of exception
> > when something (yet unknown at the time of the interface design) goes wrong.
> > But base classes (or interfaces) should not have to change when a new class
> > extends (or implements) it.
> >
> > For cases like the above, we must create a parent exception (or use an
> > existing one if it is appropriate) in order to convey that subclasses
> > _might_ throw exceptions that inherit from that one.
> > It this particular case, it seems that operators that are not positive
> > definite are illegal for method "solveInPlace", hence we conclude (not
> > surprisingly) that "MathIllegalArgumentException" can be thrown from classes
> > that implement "RealLinearOperator.solveInPlace".
> >
> > In fact, this is even too much of a "guessing" work. And this where a single
> > root can be used to clearly advertize that, by design, CM is supposed to
> > throw only (subclasses of) "MathRunimeException". _That_ exception, and
> > _nothing_ else should really be inserted in the "throws" clause of upper
> > level base classes and interfaces.
> >
> > Referring to the above example, it is the duty of the user of CM to read the
> > documentation of the (concrete) classes he uses if he wants to know which
> > subclass of "MathRuntimeException" may actually be thrown; it is not enough
> > to read the documentation of the interface!
> > To be clear, CM will become a total clutter if upper levels attempt to
> > report everything all the way down. This is in blatant contradiction with
> > the principle (or rule, or best practice) of encapsulation.
> >
> >
> > Best regards,
> > Gilles
> >
> >> > [...]
> >
> > P.S. Practically, at this point, I propose to not touch interfaces or base
> > classes, but only add the "throws" clauses where the methods actually
> > throw the exceptions, and in some cases, one level up (where it is
> > still obvious that a particular condition is required).
> > Of course, that makes it impossible to test the "switch to checked
> > exception" as the work is in progress. For this, let's wait until all
> > the first pass has been completed, then we can see what is missing,
> > and decide while seeing the picture.
> >
> I think some exceptions *must* be shown in some interfaces. For
> example, DimensionMismatchException in FieldMatrix.mul(FieldMatrix).
I didn't deny it. I suggested that _for the time being_, we add the obvious
clauses, i.e. those where the "throw" statement is visible in the body of
the function, or where we know that a method called by this method can
throw[1].
Then we can "propagate" the changes upwards, where it makes sense.
I agree that in your example, the exception should be advertized in the
interface, because this is a precondition of the operation that must hold
for _any_ implementation. [Thus you can add it now if you want ;-)].
Best regards,
Gilles
[1] E.g. like the various "verify..." utility methods.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Re: Single root for Exceptions
Posted by Sébastien Brisard <se...@m4x.org>.
Hi again,
2012/9/1 Gilles Sadowski <gi...@harfang.homelinux.org>:
> Hello.
>
>> >>>
>> >>> in ConjugateGradient, I get the following error
>> >>>
>> >>> "Exception NonPositiveDefiniteOperatorException is not compatible with
>> >>> throws clause in
>> >>> PreconditionedIterativeLinearSolver.solveInPlace(RealLinearOperator,
>> >>> RealLinearOperator, RealVector, RealVector)"
>> >>>
>> >>> This comes from the fact that general iterative solvers do not require
>> >>> positive definite operators (therefore, no
>> >>> "throws NonPositiveDefiniteOperatorException" clause in the signature of
>> >>> PreconditionedIterativeLinearSolver.solveInPlace), while conjugate
>> >>> gradient does.
>> >>>
>> >>> Do I need to add the "throws NonPositiveDefiniteOperatorException"
>> >>> clause in the signature of
>> >>> PreconditionedIterativeLinearSolver.solveInPlace as well?
>> >>
>> >> I think so, as users may use a ConjugateGradient and store it in a
>> >> variable declared with the base class only. However, I don't know if
>> >> adding an unchecked exception to the signature of an interface is a
>> >> compatible change or not.
>> >>
>> >> Luc
>> >>
>> > clirr does not seem to be complaining, so I'll do as you say. Here is
>> > what I'm planning to add to the javadoc of the mother abstract class.
>> > What do you think?
>> >
>> > * @throws NonPositiveDefiniteOperatorException if {@code a} or {@code m}
>> > * is not positive definite (required by some iterative solvers)
>>
>> Perfect!
>
> I don't agree on the principle that base classes/interfaces should be aware
> of the detailed requirements of their implementations.
> We can foresee that subclasses might need to throw _some_ kind of exception
> when something (yet unknown at the time of the interface design) goes wrong.
> But base classes (or interfaces) should not have to change when a new class
> extends (or implements) it.
>
> For cases like the above, we must create a parent exception (or use an
> existing one if it is appropriate) in order to convey that subclasses
> _might_ throw exceptions that inherit from that one.
> It this particular case, it seems that operators that are not positive
> definite are illegal for method "solveInPlace", hence we conclude (not
> surprisingly) that "MathIllegalArgumentException" can be thrown from classes
> that implement "RealLinearOperator.solveInPlace".
>
> In fact, this is even too much of a "guessing" work. And this where a single
> root can be used to clearly advertize that, by design, CM is supposed to
> throw only (subclasses of) "MathRunimeException". _That_ exception, and
> _nothing_ else should really be inserted in the "throws" clause of upper
> level base classes and interfaces.
>
> Referring to the above example, it is the duty of the user of CM to read the
> documentation of the (concrete) classes he uses if he wants to know which
> subclass of "MathRuntimeException" may actually be thrown; it is not enough
> to read the documentation of the interface!
> To be clear, CM will become a total clutter if upper levels attempt to
> report everything all the way down. This is in blatant contradiction with
> the principle (or rule, or best practice) of encapsulation.
>
>
> Best regards,
> Gilles
>
>> > [...]
>
> P.S. Practically, at this point, I propose to not touch interfaces or base
> classes, but only add the "throws" clauses where the methods actually
> throw the exceptions, and in some cases, one level up (where it is
> still obvious that a particular condition is required).
> Of course, that makes it impossible to test the "switch to checked
> exception" as the work is in progress. For this, let's wait until all
> the first pass has been completed, then we can see what is missing,
> and decide while seeing the picture.
>
I think some exceptions *must* be shown in some interfaces. For
example, DimensionMismatchException in FieldMatrix.mul(FieldMatrix).
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Re: Single root for Exceptions
Posted by Phil Steitz <ph...@gmail.com>.
On 9/2/12 7:35 PM, Sébastien Brisard wrote:
> Hi,
> here is another problem. In
> MatrixUtils.createFieldIdentityMatrix(Field<T>, int), the constructor
> Array2DRowFieldMatrix(Field<T>, T[][], boolean) is called. This
> constructor throws a DimensionMismatchException if the data array is
> not rectangular. This is never going to occur in
> createFieldIdentityMatrix, so what should we do
> 1. Populate the throws clause of createFieldIdentityMatrix with
> DimensionMismatchException anyway?
> 2. try/catch with empty catch, which I find ugly?
Neither. The exception will (provably) never be thrown. Therefore
there is no reason to advertise it.
Just allow it as an exception when applying "rhymes with truc's" trick.
What we need to accomplish is to effectively advertise all
exceptions that a caller may actually see. In some cases,
superclasses of the exceptions being propagated may be appropriate
and in extreme cases, due to holes in the hierarchy or deep nesting
of the API, the only thing that will make sense to the caller is
MRTE. This should be a last resort.
Phil
>
> Sébastien
>
> 2012/9/3 Sébastien Brisard <se...@m4x.org>:
>> Hi,
>>
>> 2012/9/1 Gilles Sadowski <gi...@harfang.homelinux.org>:
>>> Hello.
>>>
>>>>>>> in ConjugateGradient, I get the following error
>>>>>>>
>>>>>>> "Exception NonPositiveDefiniteOperatorException is not compatible with
>>>>>>> throws clause in
>>>>>>> PreconditionedIterativeLinearSolver.solveInPlace(RealLinearOperator,
>>>>>>> RealLinearOperator, RealVector, RealVector)"
>>>>>>>
>>>>>>> This comes from the fact that general iterative solvers do not require
>>>>>>> positive definite operators (therefore, no
>>>>>>> "throws NonPositiveDefiniteOperatorException" clause in the signature of
>>>>>>> PreconditionedIterativeLinearSolver.solveInPlace), while conjugate
>>>>>>> gradient does.
>>>>>>>
>>>>>>> Do I need to add the "throws NonPositiveDefiniteOperatorException"
>>>>>>> clause in the signature of
>>>>>>> PreconditionedIterativeLinearSolver.solveInPlace as well?
>>>>>> I think so, as users may use a ConjugateGradient and store it in a
>>>>>> variable declared with the base class only. However, I don't know if
>>>>>> adding an unchecked exception to the signature of an interface is a
>>>>>> compatible change or not.
>>>>>>
>>>>>> Luc
>>>>>>
>>>>> clirr does not seem to be complaining, so I'll do as you say. Here is
>>>>> what I'm planning to add to the javadoc of the mother abstract class.
>>>>> What do you think?
>>>>>
>>>>> * @throws NonPositiveDefiniteOperatorException if {@code a} or {@code m}
>>>>> * is not positive definite (required by some iterative solvers)
>>>> Perfect!
>>> I don't agree on the principle that base classes/interfaces should be aware
>>> of the detailed requirements of their implementations.
>>> We can foresee that subclasses might need to throw _some_ kind of exception
>>> when something (yet unknown at the time of the interface design) goes wrong.
>>> But base classes (or interfaces) should not have to change when a new class
>>> extends (or implements) it.
>>>
>>> For cases like the above, we must create a parent exception (or use an
>>> existing one if it is appropriate) in order to convey that subclasses
>>> _might_ throw exceptions that inherit from that one.
>>> It this particular case, it seems that operators that are not positive
>>> definite are illegal for method "solveInPlace", hence we conclude (not
>>> surprisingly) that "MathIllegalArgumentException" can be thrown from classes
>>> that implement "RealLinearOperator.solveInPlace".
>>>
>>> In fact, this is even too much of a "guessing" work. And this where a single
>>> root can be used to clearly advertize that, by design, CM is supposed to
>>> throw only (subclasses of) "MathRunimeException". _That_ exception, and
>>> _nothing_ else should really be inserted in the "throws" clause of upper
>>> level base classes and interfaces.
>>>
>>> Referring to the above example, it is the duty of the user of CM to read the
>>> documentation of the (concrete) classes he uses if he wants to know which
>>> subclass of "MathRuntimeException" may actually be thrown; it is not enough
>>> to read the documentation of the interface!
>>> To be clear, CM will become a total clutter if upper levels attempt to
>>> report everything all the way down. This is in blatant contradiction with
>>> the principle (or rule, or best practice) of encapsulation.
>>>
>> OK, but the code is going to become a total clutter anyway. Indeed, in
>> PreconditionedIterativeLinearSolver, there are a bunch of solve()
>> method, all based on the abstract method
>> public abstract RealVector solveInPlace(RealLinearOperator a,
>> RealLinearOperator m,
>> RealVector b,
>> RealVector x0)
>>
>> In conjugate gradient, the above method throws a
>> NonPositiveDefiniteOperatorException. This means that in the
>> implementation of ConjugateGradient, I need to override every single
>> solve method that are implemented in the base class, just to add the
>> proper throws clause. At this point, I have stopped "populating the
>> throws clause", as I am not sure it's the best way to go.
>> S
>>> Best regards,
>>> Gilles
>>>
>>>>> [...]
>>> P.S. Practically, at this point, I propose to not touch interfaces or base
>>> classes, but only add the "throws" clauses where the methods actually
>>> throw the exceptions, and in some cases, one level up (where it is
>>> still obvious that a particular condition is required).
>>> Of course, that makes it impossible to test the "switch to checked
>>> exception" as the work is in progress. For this, let's wait until all
>>> the first pass has been completed, then we can see what is missing,
>>> and decide while seeing the picture.
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Re: Single root for Exceptions
Posted by Sébastien Brisard <se...@m4x.org>.
Hi,
here is another problem. In
MatrixUtils.createFieldIdentityMatrix(Field<T>, int), the constructor
Array2DRowFieldMatrix(Field<T>, T[][], boolean) is called. This
constructor throws a DimensionMismatchException if the data array is
not rectangular. This is never going to occur in
createFieldIdentityMatrix, so what should we do
1. Populate the throws clause of createFieldIdentityMatrix with
DimensionMismatchException anyway?
2. try/catch with empty catch, which I find ugly?
Sébastien
2012/9/3 Sébastien Brisard <se...@m4x.org>:
> Hi,
>
> 2012/9/1 Gilles Sadowski <gi...@harfang.homelinux.org>:
>> Hello.
>>
>>> >>>
>>> >>> in ConjugateGradient, I get the following error
>>> >>>
>>> >>> "Exception NonPositiveDefiniteOperatorException is not compatible with
>>> >>> throws clause in
>>> >>> PreconditionedIterativeLinearSolver.solveInPlace(RealLinearOperator,
>>> >>> RealLinearOperator, RealVector, RealVector)"
>>> >>>
>>> >>> This comes from the fact that general iterative solvers do not require
>>> >>> positive definite operators (therefore, no
>>> >>> "throws NonPositiveDefiniteOperatorException" clause in the signature of
>>> >>> PreconditionedIterativeLinearSolver.solveInPlace), while conjugate
>>> >>> gradient does.
>>> >>>
>>> >>> Do I need to add the "throws NonPositiveDefiniteOperatorException"
>>> >>> clause in the signature of
>>> >>> PreconditionedIterativeLinearSolver.solveInPlace as well?
>>> >>
>>> >> I think so, as users may use a ConjugateGradient and store it in a
>>> >> variable declared with the base class only. However, I don't know if
>>> >> adding an unchecked exception to the signature of an interface is a
>>> >> compatible change or not.
>>> >>
>>> >> Luc
>>> >>
>>> > clirr does not seem to be complaining, so I'll do as you say. Here is
>>> > what I'm planning to add to the javadoc of the mother abstract class.
>>> > What do you think?
>>> >
>>> > * @throws NonPositiveDefiniteOperatorException if {@code a} or {@code m}
>>> > * is not positive definite (required by some iterative solvers)
>>>
>>> Perfect!
>>
>> I don't agree on the principle that base classes/interfaces should be aware
>> of the detailed requirements of their implementations.
>> We can foresee that subclasses might need to throw _some_ kind of exception
>> when something (yet unknown at the time of the interface design) goes wrong.
>> But base classes (or interfaces) should not have to change when a new class
>> extends (or implements) it.
>>
>> For cases like the above, we must create a parent exception (or use an
>> existing one if it is appropriate) in order to convey that subclasses
>> _might_ throw exceptions that inherit from that one.
>> It this particular case, it seems that operators that are not positive
>> definite are illegal for method "solveInPlace", hence we conclude (not
>> surprisingly) that "MathIllegalArgumentException" can be thrown from classes
>> that implement "RealLinearOperator.solveInPlace".
>>
>> In fact, this is even too much of a "guessing" work. And this where a single
>> root can be used to clearly advertize that, by design, CM is supposed to
>> throw only (subclasses of) "MathRunimeException". _That_ exception, and
>> _nothing_ else should really be inserted in the "throws" clause of upper
>> level base classes and interfaces.
>>
>> Referring to the above example, it is the duty of the user of CM to read the
>> documentation of the (concrete) classes he uses if he wants to know which
>> subclass of "MathRuntimeException" may actually be thrown; it is not enough
>> to read the documentation of the interface!
>> To be clear, CM will become a total clutter if upper levels attempt to
>> report everything all the way down. This is in blatant contradiction with
>> the principle (or rule, or best practice) of encapsulation.
>>
> OK, but the code is going to become a total clutter anyway. Indeed, in
> PreconditionedIterativeLinearSolver, there are a bunch of solve()
> method, all based on the abstract method
> public abstract RealVector solveInPlace(RealLinearOperator a,
> RealLinearOperator m,
> RealVector b,
> RealVector x0)
>
> In conjugate gradient, the above method throws a
> NonPositiveDefiniteOperatorException. This means that in the
> implementation of ConjugateGradient, I need to override every single
> solve method that are implemented in the base class, just to add the
> proper throws clause. At this point, I have stopped "populating the
> throws clause", as I am not sure it's the best way to go.
> S
>>
>> Best regards,
>> Gilles
>>
>>> > [...]
>>
>> P.S. Practically, at this point, I propose to not touch interfaces or base
>> classes, but only add the "throws" clauses where the methods actually
>> throw the exceptions, and in some cases, one level up (where it is
>> still obvious that a particular condition is required).
>> Of course, that makes it impossible to test the "switch to checked
>> exception" as the work is in progress. For this, let's wait until all
>> the first pass has been completed, then we can see what is missing,
>> and decide while seeing the picture.
>>
>> ---------------------------------------------------------------------
>> 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
Re: [math] Re: Single root for Exceptions
Posted by Sébastien Brisard <se...@m4x.org>.
Hi,
2012/9/1 Gilles Sadowski <gi...@harfang.homelinux.org>:
> Hello.
>
>> >>>
>> >>> in ConjugateGradient, I get the following error
>> >>>
>> >>> "Exception NonPositiveDefiniteOperatorException is not compatible with
>> >>> throws clause in
>> >>> PreconditionedIterativeLinearSolver.solveInPlace(RealLinearOperator,
>> >>> RealLinearOperator, RealVector, RealVector)"
>> >>>
>> >>> This comes from the fact that general iterative solvers do not require
>> >>> positive definite operators (therefore, no
>> >>> "throws NonPositiveDefiniteOperatorException" clause in the signature of
>> >>> PreconditionedIterativeLinearSolver.solveInPlace), while conjugate
>> >>> gradient does.
>> >>>
>> >>> Do I need to add the "throws NonPositiveDefiniteOperatorException"
>> >>> clause in the signature of
>> >>> PreconditionedIterativeLinearSolver.solveInPlace as well?
>> >>
>> >> I think so, as users may use a ConjugateGradient and store it in a
>> >> variable declared with the base class only. However, I don't know if
>> >> adding an unchecked exception to the signature of an interface is a
>> >> compatible change or not.
>> >>
>> >> Luc
>> >>
>> > clirr does not seem to be complaining, so I'll do as you say. Here is
>> > what I'm planning to add to the javadoc of the mother abstract class.
>> > What do you think?
>> >
>> > * @throws NonPositiveDefiniteOperatorException if {@code a} or {@code m}
>> > * is not positive definite (required by some iterative solvers)
>>
>> Perfect!
>
> I don't agree on the principle that base classes/interfaces should be aware
> of the detailed requirements of their implementations.
> We can foresee that subclasses might need to throw _some_ kind of exception
> when something (yet unknown at the time of the interface design) goes wrong.
> But base classes (or interfaces) should not have to change when a new class
> extends (or implements) it.
>
> For cases like the above, we must create a parent exception (or use an
> existing one if it is appropriate) in order to convey that subclasses
> _might_ throw exceptions that inherit from that one.
> It this particular case, it seems that operators that are not positive
> definite are illegal for method "solveInPlace", hence we conclude (not
> surprisingly) that "MathIllegalArgumentException" can be thrown from classes
> that implement "RealLinearOperator.solveInPlace".
>
> In fact, this is even too much of a "guessing" work. And this where a single
> root can be used to clearly advertize that, by design, CM is supposed to
> throw only (subclasses of) "MathRunimeException". _That_ exception, and
> _nothing_ else should really be inserted in the "throws" clause of upper
> level base classes and interfaces.
>
> Referring to the above example, it is the duty of the user of CM to read the
> documentation of the (concrete) classes he uses if he wants to know which
> subclass of "MathRuntimeException" may actually be thrown; it is not enough
> to read the documentation of the interface!
> To be clear, CM will become a total clutter if upper levels attempt to
> report everything all the way down. This is in blatant contradiction with
> the principle (or rule, or best practice) of encapsulation.
>
OK, but the code is going to become a total clutter anyway. Indeed, in
PreconditionedIterativeLinearSolver, there are a bunch of solve()
method, all based on the abstract method
public abstract RealVector solveInPlace(RealLinearOperator a,
RealLinearOperator m,
RealVector b,
RealVector x0)
In conjugate gradient, the above method throws a
NonPositiveDefiniteOperatorException. This means that in the
implementation of ConjugateGradient, I need to override every single
solve method that are implemented in the base class, just to add the
proper throws clause. At this point, I have stopped "populating the
throws clause", as I am not sure it's the best way to go.
S
>
> Best regards,
> Gilles
>
>> > [...]
>
> P.S. Practically, at this point, I propose to not touch interfaces or base
> classes, but only add the "throws" clauses where the methods actually
> throw the exceptions, and in some cases, one level up (where it is
> still obvious that a particular condition is required).
> Of course, that makes it impossible to test the "switch to checked
> exception" as the work is in progress. For this, let's wait until all
> the first pass has been completed, then we can see what is missing,
> and decide while seeing the picture.
>
> ---------------------------------------------------------------------
> 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
Re: [math] Re: Single root for Exceptions
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello.
> >>>
> >>> in ConjugateGradient, I get the following error
> >>>
> >>> "Exception NonPositiveDefiniteOperatorException is not compatible with
> >>> throws clause in
> >>> PreconditionedIterativeLinearSolver.solveInPlace(RealLinearOperator,
> >>> RealLinearOperator, RealVector, RealVector)"
> >>>
> >>> This comes from the fact that general iterative solvers do not require
> >>> positive definite operators (therefore, no
> >>> "throws NonPositiveDefiniteOperatorException" clause in the signature of
> >>> PreconditionedIterativeLinearSolver.solveInPlace), while conjugate
> >>> gradient does.
> >>>
> >>> Do I need to add the "throws NonPositiveDefiniteOperatorException"
> >>> clause in the signature of
> >>> PreconditionedIterativeLinearSolver.solveInPlace as well?
> >>
> >> I think so, as users may use a ConjugateGradient and store it in a
> >> variable declared with the base class only. However, I don't know if
> >> adding an unchecked exception to the signature of an interface is a
> >> compatible change or not.
> >>
> >> Luc
> >>
> > clirr does not seem to be complaining, so I'll do as you say. Here is
> > what I'm planning to add to the javadoc of the mother abstract class.
> > What do you think?
> >
> > * @throws NonPositiveDefiniteOperatorException if {@code a} or {@code m}
> > * is not positive definite (required by some iterative solvers)
>
> Perfect!
I don't agree on the principle that base classes/interfaces should be aware
of the detailed requirements of their implementations.
We can foresee that subclasses might need to throw _some_ kind of exception
when something (yet unknown at the time of the interface design) goes wrong.
But base classes (or interfaces) should not have to change when a new class
extends (or implements) it.
For cases like the above, we must create a parent exception (or use an
existing one if it is appropriate) in order to convey that subclasses
_might_ throw exceptions that inherit from that one.
It this particular case, it seems that operators that are not positive
definite are illegal for method "solveInPlace", hence we conclude (not
surprisingly) that "MathIllegalArgumentException" can be thrown from classes
that implement "RealLinearOperator.solveInPlace".
In fact, this is even too much of a "guessing" work. And this where a single
root can be used to clearly advertize that, by design, CM is supposed to
throw only (subclasses of) "MathRunimeException". _That_ exception, and
_nothing_ else should really be inserted in the "throws" clause of upper
level base classes and interfaces.
Referring to the above example, it is the duty of the user of CM to read the
documentation of the (concrete) classes he uses if he wants to know which
subclass of "MathRuntimeException" may actually be thrown; it is not enough
to read the documentation of the interface!
To be clear, CM will become a total clutter if upper levels attempt to
report everything all the way down. This is in blatant contradiction with
the principle (or rule, or best practice) of encapsulation.
Best regards,
Gilles
> > [...]
P.S. Practically, at this point, I propose to not touch interfaces or base
classes, but only add the "throws" clauses where the methods actually
throw the exceptions, and in some cases, one level up (where it is
still obvious that a particular condition is required).
Of course, that makes it impossible to test the "switch to checked
exception" as the work is in progress. For this, let's wait until all
the first pass has been completed, then we can see what is missing,
and decide while seeing the picture.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Re: Single root for Exceptions
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 01/09/2012 10:42, Sébastien Brisard a écrit :
> Hi Luc,
>
> 2012/9/1 Luc Maisonobe <Lu...@free.fr>:
>> Le 01/09/2012 10:03, Sébastien Brisard a écrit :
>>> Hi,
>>>
>>> in ConjugateGradient, I get the following error
>>>
>>> "Exception NonPositiveDefiniteOperatorException is not compatible with
>>> throws clause in
>>> PreconditionedIterativeLinearSolver.solveInPlace(RealLinearOperator,
>>> RealLinearOperator, RealVector, RealVector)"
>>>
>>> This comes from the fact that general iterative solvers do not require
>>> positive definite operators (therefore, no
>>> "throws NonPositiveDefiniteOperatorException" clause in the signature of
>>> PreconditionedIterativeLinearSolver.solveInPlace), while conjugate
>>> gradient does.
>>>
>>> Do I need to add the "throws NonPositiveDefiniteOperatorException"
>>> clause in the signature of
>>> PreconditionedIterativeLinearSolver.solveInPlace as well?
>>
>> I think so, as users may use a ConjugateGradient and store it in a
>> variable declared with the base class only. However, I don't know if
>> adding an unchecked exception to the signature of an interface is a
>> compatible change or not.
>>
>> Luc
>>
> clirr does not seem to be complaining, so I'll do as you say. Here is
> what I'm planning to add to the javadoc of the mother abstract class.
> What do you think?
>
> * @throws NonPositiveDefiniteOperatorException if {@code a} or {@code m}
> * is not positive definite (required by some iterative solvers)
Perfect!
thanks,
Luc
>
>
> Sébastien
>
>>>
>>> Sébastien
>>>
>>> 2012/9/1 Sébastien Brisard <se...@m4x.org>:
>>>> Hello,
>>>>
>>>>
>>>> 2012/8/31 Thomas Neidhart <th...@gmail.com>:
>>>>> On 08/31/2012 11:17 AM, Luc Maisonobe wrote:
>>>>>> Le 31/08/2012 03:22, Sébastien Brisard a écrit :
>>>>>>> Hello,
>>>>>>>
>>>>>>>>>>> [...]
>>>>>>>>>>>
>>>>>>>>>>> Thus, shall I open a JIRA ticket with the tasks of completing the "throws"
>>>>>>>>>>> clauses of all CM methods?
>>>>>>>>>>> Does someone absolutely needs this task tobe completed before releasing 3.1?
>>>>>>>>>>> [I don't think that it's possible without a huge effort from everyone.]
>>>>>>>>>
>>>>>>>>> Ticket created:
>>>>>>>>> https://issues.apache.org/jira/browse/MATH-854
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> No hurry on my side, but I'm happy contributing. In order not to tread
>>>>>>>>>> on anyone's feet, maybe each of us should be assigned one package (for
>>>>>>>>>> a start).
>>>>>>>>>
>>>>>>>>> Good idea.
>>>>>>>>>
>>>>>>>>> Gilles: packages "o.a.c.m.optimization"
>>>>>>>>> "o.a.c.m.analysis.function"
>>>>>>>>> "o.a.c.m.analysis.solvers"
>>>>>>>>> "o.a.c.m.analysis.integration"
>>>>>>>>> "o.a.c.m.analysis.interpolation"
>>>>>>>>
>>>>>>>> +1 to divide and conquer. I will start on stat.
>>>>>>>>
>>>>>>>> Phil
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Gilles
>>>>>>>>>
>>>>>>> I can take care of linear and special, of course!
>>>>>>
>>>>>> I'll look at ode, differentiation and geometry.
>>>>>
>>>>> I will start with filter and genetics.
>>>>>
>>>>> Thomas
>>>>>
>>>> Just to make sure I don't forget anything... We must apply
>>>> you-know-who's trick to 4 and only 4 exception types
>>>> - MathArithmeticException
>>>> - MathIllegalArgumentException
>>>> - MathIllegalStateException
>>>> - MathUnsupportedOperationException
>>>>
>>>> Is that correct?
>>>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: [math] Re: Single root for Exceptions
Posted by Sébastien Brisard <se...@m4x.org>.
Hi Luc,
2012/9/1 Luc Maisonobe <Lu...@free.fr>:
> Le 01/09/2012 10:03, Sébastien Brisard a écrit :
>> Hi,
>>
>> in ConjugateGradient, I get the following error
>>
>> "Exception NonPositiveDefiniteOperatorException is not compatible with
>> throws clause in
>> PreconditionedIterativeLinearSolver.solveInPlace(RealLinearOperator,
>> RealLinearOperator, RealVector, RealVector)"
>>
>> This comes from the fact that general iterative solvers do not require
>> positive definite operators (therefore, no
>> "throws NonPositiveDefiniteOperatorException" clause in the signature of
>> PreconditionedIterativeLinearSolver.solveInPlace), while conjugate
>> gradient does.
>>
>> Do I need to add the "throws NonPositiveDefiniteOperatorException"
>> clause in the signature of
>> PreconditionedIterativeLinearSolver.solveInPlace as well?
>
> I think so, as users may use a ConjugateGradient and store it in a
> variable declared with the base class only. However, I don't know if
> adding an unchecked exception to the signature of an interface is a
> compatible change or not.
>
> Luc
>
clirr does not seem to be complaining, so I'll do as you say. Here is
what I'm planning to add to the javadoc of the mother abstract class.
What do you think?
* @throws NonPositiveDefiniteOperatorException if {@code a} or {@code m}
* is not positive definite (required by some iterative solvers)
Sébastien
>>
>> Sébastien
>>
>> 2012/9/1 Sébastien Brisard <se...@m4x.org>:
>>> Hello,
>>>
>>>
>>> 2012/8/31 Thomas Neidhart <th...@gmail.com>:
>>>> On 08/31/2012 11:17 AM, Luc Maisonobe wrote:
>>>>> Le 31/08/2012 03:22, Sébastien Brisard a écrit :
>>>>>> Hello,
>>>>>>
>>>>>>>>>> [...]
>>>>>>>>>>
>>>>>>>>>> Thus, shall I open a JIRA ticket with the tasks of completing the "throws"
>>>>>>>>>> clauses of all CM methods?
>>>>>>>>>> Does someone absolutely needs this task tobe completed before releasing 3.1?
>>>>>>>>>> [I don't think that it's possible without a huge effort from everyone.]
>>>>>>>>
>>>>>>>> Ticket created:
>>>>>>>> https://issues.apache.org/jira/browse/MATH-854
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No hurry on my side, but I'm happy contributing. In order not to tread
>>>>>>>>> on anyone's feet, maybe each of us should be assigned one package (for
>>>>>>>>> a start).
>>>>>>>>
>>>>>>>> Good idea.
>>>>>>>>
>>>>>>>> Gilles: packages "o.a.c.m.optimization"
>>>>>>>> "o.a.c.m.analysis.function"
>>>>>>>> "o.a.c.m.analysis.solvers"
>>>>>>>> "o.a.c.m.analysis.integration"
>>>>>>>> "o.a.c.m.analysis.interpolation"
>>>>>>>
>>>>>>> +1 to divide and conquer. I will start on stat.
>>>>>>>
>>>>>>> Phil
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Gilles
>>>>>>>>
>>>>>> I can take care of linear and special, of course!
>>>>>
>>>>> I'll look at ode, differentiation and geometry.
>>>>
>>>> I will start with filter and genetics.
>>>>
>>>> Thomas
>>>>
>>> Just to make sure I don't forget anything... We must apply
>>> you-know-who's trick to 4 and only 4 exception types
>>> - MathArithmeticException
>>> - MathIllegalArgumentException
>>> - MathIllegalStateException
>>> - MathUnsupportedOperationException
>>>
>>> Is that correct?
>>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Re: Single root for Exceptions
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 01/09/2012 10:03, Sébastien Brisard a écrit :
> Hi,
>
> in ConjugateGradient, I get the following error
>
> "Exception NonPositiveDefiniteOperatorException is not compatible with
> throws clause in
> PreconditionedIterativeLinearSolver.solveInPlace(RealLinearOperator,
> RealLinearOperator, RealVector, RealVector)"
>
> This comes from the fact that general iterative solvers do not require
> positive definite operators (therefore, no
> "throws NonPositiveDefiniteOperatorException" clause in the signature of
> PreconditionedIterativeLinearSolver.solveInPlace), while conjugate
> gradient does.
>
> Do I need to add the "throws NonPositiveDefiniteOperatorException"
> clause in the signature of
> PreconditionedIterativeLinearSolver.solveInPlace as well?
I think so, as users may use a ConjugateGradient and store it in a
variable declared with the base class only. However, I don't know if
adding an unchecked exception to the signature of an interface is a
compatible change or not.
Luc
>
> Sébastien
>
> 2012/9/1 Sébastien Brisard <se...@m4x.org>:
>> Hello,
>>
>>
>> 2012/8/31 Thomas Neidhart <th...@gmail.com>:
>>> On 08/31/2012 11:17 AM, Luc Maisonobe wrote:
>>>> Le 31/08/2012 03:22, Sébastien Brisard a écrit :
>>>>> Hello,
>>>>>
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>> Thus, shall I open a JIRA ticket with the tasks of completing the "throws"
>>>>>>>>> clauses of all CM methods?
>>>>>>>>> Does someone absolutely needs this task tobe completed before releasing 3.1?
>>>>>>>>> [I don't think that it's possible without a huge effort from everyone.]
>>>>>>>
>>>>>>> Ticket created:
>>>>>>> https://issues.apache.org/jira/browse/MATH-854
>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> No hurry on my side, but I'm happy contributing. In order not to tread
>>>>>>>> on anyone's feet, maybe each of us should be assigned one package (for
>>>>>>>> a start).
>>>>>>>
>>>>>>> Good idea.
>>>>>>>
>>>>>>> Gilles: packages "o.a.c.m.optimization"
>>>>>>> "o.a.c.m.analysis.function"
>>>>>>> "o.a.c.m.analysis.solvers"
>>>>>>> "o.a.c.m.analysis.integration"
>>>>>>> "o.a.c.m.analysis.interpolation"
>>>>>>
>>>>>> +1 to divide and conquer. I will start on stat.
>>>>>>
>>>>>> Phil
>>>>>>>
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Gilles
>>>>>>>
>>>>> I can take care of linear and special, of course!
>>>>
>>>> I'll look at ode, differentiation and geometry.
>>>
>>> I will start with filter and genetics.
>>>
>>> Thomas
>>>
>> Just to make sure I don't forget anything... We must apply
>> you-know-who's trick to 4 and only 4 exception types
>> - MathArithmeticException
>> - MathIllegalArgumentException
>> - MathIllegalStateException
>> - MathUnsupportedOperationException
>>
>> Is that correct?
>> 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
Re: [math] Re: Single root for Exceptions
Posted by Sébastien Brisard <se...@m4x.org>.
Hi,
in ConjugateGradient, I get the following error
"Exception NonPositiveDefiniteOperatorException is not compatible with
throws clause in
PreconditionedIterativeLinearSolver.solveInPlace(RealLinearOperator,
RealLinearOperator, RealVector, RealVector)"
This comes from the fact that general iterative solvers do not require
positive definite operators (therefore, no
"throws NonPositiveDefiniteOperatorException" clause in the signature of
PreconditionedIterativeLinearSolver.solveInPlace), while conjugate
gradient does.
Do I need to add the "throws NonPositiveDefiniteOperatorException"
clause in the signature of
PreconditionedIterativeLinearSolver.solveInPlace as well?
Sébastien
2012/9/1 Sébastien Brisard <se...@m4x.org>:
> Hello,
>
>
> 2012/8/31 Thomas Neidhart <th...@gmail.com>:
>> On 08/31/2012 11:17 AM, Luc Maisonobe wrote:
>>> Le 31/08/2012 03:22, Sébastien Brisard a écrit :
>>>> Hello,
>>>>
>>>>>>>> [...]
>>>>>>>>
>>>>>>>> Thus, shall I open a JIRA ticket with the tasks of completing the "throws"
>>>>>>>> clauses of all CM methods?
>>>>>>>> Does someone absolutely needs this task tobe completed before releasing 3.1?
>>>>>>>> [I don't think that it's possible without a huge effort from everyone.]
>>>>>>
>>>>>> Ticket created:
>>>>>> https://issues.apache.org/jira/browse/MATH-854
>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> No hurry on my side, but I'm happy contributing. In order not to tread
>>>>>>> on anyone's feet, maybe each of us should be assigned one package (for
>>>>>>> a start).
>>>>>>
>>>>>> Good idea.
>>>>>>
>>>>>> Gilles: packages "o.a.c.m.optimization"
>>>>>> "o.a.c.m.analysis.function"
>>>>>> "o.a.c.m.analysis.solvers"
>>>>>> "o.a.c.m.analysis.integration"
>>>>>> "o.a.c.m.analysis.interpolation"
>>>>>
>>>>> +1 to divide and conquer. I will start on stat.
>>>>>
>>>>> Phil
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Gilles
>>>>>>
>>>> I can take care of linear and special, of course!
>>>
>>> I'll look at ode, differentiation and geometry.
>>
>> I will start with filter and genetics.
>>
>> Thomas
>>
> Just to make sure I don't forget anything... We must apply
> you-know-who's trick to 4 and only 4 exception types
> - MathArithmeticException
> - MathIllegalArgumentException
> - MathIllegalStateException
> - MathUnsupportedOperationException
>
> Is that correct?
> Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org