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 Sun, 02 Sep 2012 12:00:36 GMT
Hi again.

> > 
> > > 
> > >>>
> > >>>>>> [...]
> > >>>>>> I encountered this need in two different cases. The first
one was to
> > >>>>>> identify very precisely an error type, even with finer
granularity than
> > >>>>>> exception type. Parsing the error message to recognize
the exception is
> > >>>>>> evil, checking the enumerate used in the pattern is less
evil. The
> > >>>>>> second case was when I needed to create a more elaborate
message by
> > >>>>>> combining some information provided by the caller, and
some information
> > >>>>>> extracted from the exception. Here again, parsing is evil
but getting
> > >>>>>> the parameters is fine.
> > >>>>>
> > >>>>> Maybe you missed my point (same as above), as it applies here
too: You can
> > >>>>> get the parameters through the accessors (of the specific exception
types).
> > >>>>> We created the "context" so that additional parameters can
be set and
> > >>>>> retrieved ("key/value" pairs). I still do not understand why
one should
> > >>>>> resort to extract something from the pattern.
> > >>>>> [The pattern is unfortunately "public" whereas it should be
an
> > >>>>> "implementation detail".]
> > >>>>
> > >>>> I don't "extract" something from the pattern, I just check if it
is a
> > >>>> known and expected enumerate I want to handle specifically or something
> > >>>> else.
> > >>>
> > >>> Maybe I should see the actual code before we go on discussing this.
Of
> > >>> course you are free to do whatever the API of CM lets you do. I just
have
> > >>> the feeling that I would do it otherwise... :-}
> > >>
> > >> Here is an example I encountered two minutes ago, while working on
> > >> adding the exception throws statements in the ode package.
> > >>
> > >> The computeParameterJacobian may throw a MathIllegalArgumentException
> > >> (in the current subversion repository, I have seen it throws an
> > >> IllegalArgumentException, which is wrong). In the following piece of
> > >> code, I need to check the exception I get is really a
> > >> LocalizedFormats.UNKNOWN_PARAMETER or something else:
> > >>
> > >>
> > >>   delayedExcpetion = null;
> > >>   for (ParameterJacobianProvider provider: jacobianProviders) {
> > >>
> > >>     try {
> > >>
> > >>       provider.computeParameterJacobian(...);
> > >>       return;
> > >>
> > >>     } catch (MathIllegalArgumentException miae) {
> > >>       List<Localizable> patterns = miae.getContext().getPatterns();
> > >>       if (patterns.contains(LocalizedFormats.UNKNOWN_PARAMETER)) {
> > >>         // temporarily ignore, until we have checked all providers
> > >>         delayedException = miae;
> > >>       } else {
> > >>         // this is another problem, report it
> > >>         throw miae;
> > >>       }
> > >>     }
> > >>
> > >>   }
> > >>
> > >>   if (delayedException != null) {
> > >>     // none of the providers did handle the parameters
> > >>     throw miae;
> > >>   }

I'd like to stress that using exceptions for control flow is, by default, an
anti-pattern.  It should pose question about how to improve CM so that you
don't have to fall back on this kind of construct...

IIUC the above code, the problem that might occur is not a complex
computation that fails, but a "wrong" usage (from the viewpoint of the
called code) due to a missing parameter. Wouldn't it be possible to have a
checking method in "ParameterJacobianProvider" such as

  public boolean isValidParameter(String ... paramNames) {
    // return "true" if all passed parameters are known,
    // false otherwise.
  }

and "somehow" make the check in order to avoid making a call that will fail?


Best regards,
Gilles

> [...]

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


Mime
View raw message