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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
