Oliver Heger wrote:
> 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.
The problem is then, that a user will have to check the type of the returned
object. He can never know if one or more values have been added with the
same label. The label numbering has the advantage to enable an easy
iteration about the keys and the stored values. Opinions?
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
