I think that the basic request here is for a version of StringUtils that throws NPE on null input.
This seems perfectly acceptable as a requirement, but it is different to the main StringUtils requirement of quiet null handling. For a 2.1/3.0 release, I would be happy to see a StringUtilsNPE (or similar name) added to [lang]. It would have most of the same methods as StringUtils, but handle nulls by NPE. Stephen ----- Original Message ----- From: <[EMAIL PROTECTED]> To: "'Jakarta Commons Developers List'" <[EMAIL PROTECTED]> Sent: Sunday, July 20, 2003 2:55 AM Subject: RE: [lang] StringUtils isEmpty summary(2) > > d) The isXxxOrNull() naming is disliked as too long even > > though its clear. > > I don't agree with this. I'm very much in favor of precise, > "intention-revealing" names. IMHO, isEmpty is unambiguous and should > only mean that there's no content in the referenced String (that is, > string.length() == 0). Empty means that there's some container that > _could_ hold something, but null means that there's no container there > at all (in a sense, string.length() == N/A). So, isEmptyOrNull() seems > very straightforward and would remove all doubt that it's checking for > null. > > > e) Similarly isEmptyTrimmed() naming is too long. > > I don't mind the length, but then I'm not sure here if it's checking for > nulls. > > > f) More people want isEmpty() to be true for null than false. > > I can't disagree with that. While I for sure don't want isEmpty() to > return true for a null (it's not empty, there's no 'it' there to > check!), I'm not sure I like isEmpty() returning false for a null > either, so a NPE would be appropriate. > > I would say that my most common usage is a replacement for: > > if ( ( string == null ) || ( string.length() == 0 ) ) > > So I'd be using isEmptyOrNull( string ). > > However, there certainly are times that I don't want a null to silently > return false (such as when there's a contract with the rest of the code > that nulls should not exist for this variable) and I'd use isEmpty( > string ) in that case, fully expecting that if string == null, then a > NPE would be thrown and I'd have the underlying bug fixed. > > ;ted > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
