> I don't how we can use the same arguments in both the general and
> specific messages and later combine them together.
The place holders {0}, {1}, ... will be replaced by the corresponding
argument in both the "specific" and the "general" patterns.
> How is this different
> from a more complete message ?
It is not different, for your use-case (i.e. the detailed message will contain
the same information as before).
The "general" pattern describes the problem (what precondition was violated)
and is tied to the exception, so the developer does not have to copy/paste,
time and again, the pattern.
The "specific" pattern is optional but can be used to discriminate between
different contexts, if so desired (or required, should I say). Some
examples:
---Ex 1---
if (mean <= 0) {
throw new NotStrictlyPositiveException(LocalizedFormats.MEAN, mean);
}
------
---Ex 2---
if (len <= 0) {
throw new NotStrictlyPositiveException(LocalizedFormats.LENGTH,
len);
}
----
---Ex 3---
if (k <= 0) {
throw new
NotStrictlyPositiveException(LocalizedFormats.NUMBER_OF_SAMPLES, k);
}
------
In all cases, the general problem is the same, but the specific context
will make the detailed message well... more specific.
Then the same existing (in "LocalizedFormats") specific concept might be
involved
in another general problem (also existing), in which case we won't have to add
any new complete pattern: the new message will be created for the combination
of the existing patterns.
Of course, since you ask, I don't particularly like to see these
"LocalizedFormats" everywhere in the CM code; I hoped that they would be
encapsulated inside the exception classes. This is indeed no improvement
over the previous state of affairs (it's not worse anyways), but at least
now we have stateful exceptions that by themselves are potentially more
useful than a plain "IllegalArgumentException".
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
