Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <11590900.1194283910628.JavaMail.jira@brutus>
Date: Mon, 5 Nov 2007 09:31:50 -0800 (PST)
From: "Paul Benedict (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Commented: (LANG-360) Why does appendIdentityToString return
 null?
In-Reply-To: <12224872.1192969370591.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/LANG-360?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel#action_12540224 ]=20

Paul Benedict commented on LANG-360:
------------------------------------

Stephen says: "This method is meant to simulate the identity toString". Bas=
ed on his words, I concur that passing a null object should throw an except=
ion.=20

Thus I recommend:
(1) return void to get rid of method chaining=20
(2) throw an exception is StringBuffer is null
(3) throw an exception if Object is null

#3 makes most sense. There is no identity to a null object.


> Why does appendIdentityToString return null?
> --------------------------------------------
>
>                 Key: LANG-360
>                 URL: https://issues.apache.org/jira/browse/LANG-360
>             Project: Commons Lang
>          Issue Type: Bug
>            Reporter: J=C3=B6rg Gottschling
>             Fix For: 2.4
>
>         Attachments: LANG-360.patch
>
>
> ObjectUtils is designed to handle null imputs gracefully. But ObjectUtils=
.appendIdentityToString does not. It returns null unnessecary if you pass n=
ull als second parameter (the object to get the identity from). For example=
 appendIdentityToString(new StringBuffer(), null) will return null! Which i=
s an uncommen behaviour. Think about code like this:
> ObjectUtils.appendIdentityToString(buffer, param1)
>                     .appendIdentityToString(buffer, param2)
>                     .appendIdentityToString(buffer, param3);
> This will cause an NPE if param1 or param2 ist null. There may be other c=
ode where a NPE will not happen, but the code is used for debugging and the=
re will be an unexpected or wrong output.
> So you shoul return the StringBuffer which is passed in or a new one if n=
ull. The harder question is what to do with the object. I think we should a=
ppend "null" to the StringBuffer, because this is what I would expect and w=
hat the passed reference is.

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.