You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2010/11/29 01:16:29 UTC
[math] Eliminating MaxIterationsExceededException
Completing the fix for MATH-414, I saw that ContinuedFraction still throws
MaxIterationsExceededException. I thought it would be good to eliminate the
use of the deprecated exception in trunk, but I got stuck because the
replacement, MaxCountExceededException does not allow the initial argument
to be passed and reported in the message. In ContinuedFraction, we have
{code}
if (n >= maxIterations) {
throw new MaxIterationsExceededException(maxIterations,
LocalizedFormats.NON_CONVERGENT_CONTINUED_FRACTION,
x);
}
{code}
but MaxIterationsExceededException does not allow x to be passed in. Should
we add a constructor similar to what MaxIterationsExceededException has
taking an Object[] to hold additional message parameters?
Phil
Re: [math] Eliminating MaxIterationsExceededException
Posted by Phil Steitz <ph...@gmail.com>.
On Sun, Nov 28, 2010 at 8:47 PM, Gilles Sadowski <
gilles@harfang.homelinux.org> wrote:
> > Completing the fix for MATH-414, I saw that ContinuedFraction still
> throws
> > MaxIterationsExceededException. I thought it would be good to eliminate
> the
> > use of the deprecated exception in trunk, but I got stuck because the
> > replacement, MaxCountExceededException does not allow the initial
> argument
> > to be passed and reported in the message. In ContinuedFraction, we have
> > {code}
> > if (n >= maxIterations) {
> > throw new MaxIterationsExceededException(maxIterations,
> > LocalizedFormats.NON_CONVERGENT_CONTINUED_FRACTION,
> > x);
> > }
> > {code}
> >
> > but MaxIterationsExceededException does not allow x to be passed in.
> Should
> > we add a constructor similar to what MaxIterationsExceededException has
> > taking an Object[] to hold additional message parameters?
>
> I've just committed (revision 1040003) the addition of a vararg parameter
> to
> the contructor that takes a "specific" message pattern. I also changed the
> "NON_CONVERGENT_CONTINUED_FRACTION" pattern in order that the additional
> argument will actually appear in the message. The exception would thus be
> used as
> ---CUT---
> new
> MaxCountExceededException(LocalizedFormats.NON_CONVERGENT_CONTINUED_FRACTION,
> maxIterations, x);
> ---CUT---
>
> Thanks, Gilles!
Phil
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [math] Eliminating MaxIterationsExceededException
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> Completing the fix for MATH-414, I saw that ContinuedFraction still throws
> MaxIterationsExceededException. I thought it would be good to eliminate the
> use of the deprecated exception in trunk, but I got stuck because the
> replacement, MaxCountExceededException does not allow the initial argument
> to be passed and reported in the message. In ContinuedFraction, we have
> {code}
> if (n >= maxIterations) {
> throw new MaxIterationsExceededException(maxIterations,
> LocalizedFormats.NON_CONVERGENT_CONTINUED_FRACTION,
> x);
> }
> {code}
>
> but MaxIterationsExceededException does not allow x to be passed in. Should
> we add a constructor similar to what MaxIterationsExceededException has
> taking an Object[] to hold additional message parameters?
I've just committed (revision 1040003) the addition of a vararg parameter to
the contructor that takes a "specific" message pattern. I also changed the
"NON_CONVERGENT_CONTINUED_FRACTION" pattern in order that the additional
argument will actually appear in the message. The exception would thus be
used as
---CUT---
new MaxCountExceededException(LocalizedFormats.NON_CONVERGENT_CONTINUED_FRACTION,
maxIterations, x);
---CUT---
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org