commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@oliver-heger.de>
Subject Re: [lang] Time for RC3?
Date Tue, 05 Jul 2011 19:23:12 GMT
Am 05.07.2011 00:17, schrieb Jörg Schaible:
> 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?

Well, the API could be extended to have a getValues(String) method which 
always returns a list. getValue(String) could per default return the 
first value (if any).

With the index-approach in property names it seems to be harder to 
collect all values for a given key.

But I don't have strong feelings about this.

Oliver

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


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


Mime
View raw message