Hi Jörg,
Am 02.07.2011 16:28, schrieb Jörg Schaible:
Hi,
Henri Yandell wrote:
These are the current blocking items in play afaik:
* Email thread - what else should implement Formattable?
* LANG-696/Email thread - getShortName. What to do with the (String)
variant. Remove others.
* Email thread - Validate method naming
Can somebody else give the ContextedException stuff a review? I used in the
meanwhile a copy of it in a project, but a method name is bugging me.
What's it about? The exception provides a context for additional
information, just think of a map with key/value pairs. The problem that it
solves:
Instead of writing:
throw new MyCommunicationException("The connection to " + host + ':' + port
+ " failed for " + user + " because of invalid credentials");
you have:
throw new MyCommunicationException("Invalid credentials for
connection").addValue("host", host).addValue("port", port).addValue("user",
user);
And you're able to enrich the context in a bigger scope:
try {
...
} (catch MyCommunicationException e) {
throw e.addValue("Module", "backup");
}
Fine so far. The values are properly formatted in table form in case of a
message and you may even access the individual values. A problem arises in
recursive algorithms (e.g. SAX Handler) with:
try {
...
} (catch MyException e) {
throw e.addValue("Current Handler", handler.class.getName())
.addValue("Current Line", line);
}
This would normally clobber the "Current Handler" in a nested handler
situation. Our implementation will therefore detect the key clash and add
the new value with key "Current Handler[1]" (and will increase the index for
more values). However, the current line in the processed XML is always the
same and does not change, but would be added over and over again for each
recursive step.
Therefore the ExceptionContext defines the method "replaceValue(key, value)"
... and this is bugging me, since for me it is "setValue(key, value)".
Typically *I* would use setValue for the normal case and only in recursive
situations addValue. Can somebody review this interface and also the method
documentation, because *I* have a clear idea what add/set should do, but the
method description gives a lot of possibilities about its purpose and how it
can be implemented. What do you think about this API?
I tend to agree with your arguments. At least I think that
implementations would behave in a more predictable way if the
documentation was clearer. Statements like "it depends on the
implementation what happens with the new value" are not that helpful.
For addProperty() I would even expect that if multiple values with the
same key are added, a collection is created. This seems more natural to
me than automatically creating keys with indices.
Oliver
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
