commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [lang] Time for RC3?
Date Sun, 03 Jul 2011 21:04:42 GMT
On Jul 3, 2011, at 13:39, Oliver Heger <oliver.heger@oliver-heger.de> 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?

I would look at this differently to get 3.0 out the door: Let's make
sure we do not make anything Formattable that we might have to back
out later.

Gary
>>> * 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-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
>

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


Mime
View raw message