Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of garydgregory@gmail.com
 designates 209.85.161.52 as permitted sender)
References: <BANLkTi=j5GaApOjwnhRnT6uO7F2Uoag_=g@mail.gmail.com>
 <BANLkTimrsnYU5MddAWLA_4=c2HtYHnGGGw@mail.gmail.com>
 <iun9v9$crb$1@dough.gmane.org>
 <22663375.292.1309714793287.JavaMail.mobile-sync@bfkl35>
From: Gary Gregory <garydgregory@gmail.com>
In-Reply-To: <22663375.292.1309714793287.JavaMail.mobile-sync@bfkl35>
Mime-Version: 1.0 (iPhone Mail 8J2)
Date: Sun, 3 Jul 2011 17:04:42 -0400
Message-ID: <2093547918556106576@unknownmsgid>
Subject: Re: [lang] Time for RC3?
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Jul 3, 2011, at 13:39, Oliver Heger <oliver.heger@oliver-heger.de> wrote=
:

> Hi J=C3=B6rg,
>
> Am 02.07.2011 16:28, schrieb J=C3=B6rg 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 + ':' + p=
ort
>> + " failed for " + user + " because of invalid credentials");
>>
>> you have:
>>
>> throw new MyCommunicationException("Invalid credentials for
>> connection").addValue("host", host).addValue("port", port).addValue("use=
r",
>> 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 ad=
d
>> 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 t=
he
>> same and does not change, but would be added over and over again for eac=
h
>> recursive step.
>>
>> Therefore the ExceptionContext defines the method "replaceValue(key, val=
ue)"
>> ... 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 recursi=
ve
>> situations addValue. Can somebody review this interface and also the met=
hod
>> 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 ho=
w 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=C3=B6rg
>>
>>
>> ---------------------------------------------------------------------
>> 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