You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <fl...@gmail.com> on 2009/04/09 10:43:43 UTC
[LANG] Null-protection methods
Is the following worth keeping in Lang?
public Foo someJdkMethod(Object input) {
if(input == null) {
handleAccordingly();
}
return input.jdkMethod();
}
I feel that we've bloated up with these methods, and is it really
worth it? I still have lots of if(x != null && x.callFoo()) type
invocations, having a small handful of methods available in Lang to
let me say if(FooUtils.callFoo(x)) isn't enough to hide all of the
other times when I might have to worry about it.
Personally I'd like to see these methods removed from Lang [especially
given Stephen's blogging about null protected setting in some future
JVM].
An example:
public static String trim(String str) {
return str == null ? null : str.trim();
}
Given that I'm likely to do N things to the string, chances are I'll
check for null up front and then invoke methods rather than repeatedly
writing ugly code by using StringUtils.
Any thoughts in favour of these methods?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Null-protection methods
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Henri Yandell wrote:
> Is the following worth keeping in Lang?
Yes. Its a neat way of managing nulls, and the Java gods are actually
pretty opposed to the null suggestions IIUC.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Null-protection methods
Posted by Sujit Pal <su...@comcast.net>.
I am guessing methods such as StringUtils.trim() are included? If so, I
would like to say that a lot of times we use the StringUtils version
over the native String version because the StringUtils one is null-safe.
So taking these out would probably hurt users, at least until
null-safety (or NoneType or whatever) is built into the JDK.
-sujit
On Thu, 2009-04-09 at 06:43 -0400, James Carman wrote:
> On Thu, Apr 9, 2009 at 4:43 AM, Henri Yandell <fl...@gmail.com> wrote:
> > Is the following worth keeping in Lang?
> >
> > public Foo someJdkMethod(Object input) {
> > if(input == null) {
> > handleAccordingly();
> > }
> > return input.jdkMethod();
> > }
> >
> > I feel that we've bloated up with these methods, and is it really
> > worth it? I still have lots of if(x != null && x.callFoo()) type
> > invocations, having a small handful of methods available in Lang to
> > let me say if(FooUtils.callFoo(x)) isn't enough to hide all of the
> > other times when I might have to worry about it.
> >
> > Personally I'd like to see these methods removed from Lang [especially
> > given Stephen's blogging about null protected setting in some future
> > JVM].
> >
> > An example:
> >
> > public static String trim(String str) {
> > return str == null ? null : str.trim();
> > }
> >
> > Given that I'm likely to do N things to the string, chances are I'll
> > check for null up front and then invoke methods rather than repeatedly
> > writing ugly code by using StringUtils.
> >
> > Any thoughts in favour of these methods?
>
> What do bug catchers such as FindBugs do with situations like these?
> Would they still report it as a potential bug? Or, do they dig into
> the FooUtils.callFoo() methods to see if they're doing the null check?
> I'm just curious, I guess. If FindBugs is still going to report it
> as a potential bug, then it would seem like folks would probably be
> doing the null check on their own to quiet down FindBugs (not that
> everyone uses it of course).
>
> ---------------------------------------------------------------------
> 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
Re: [LANG] Null-protection methods
Posted by James Carman <ja...@carmanconsulting.com>.
On Thu, Apr 9, 2009 at 4:43 AM, Henri Yandell <fl...@gmail.com> wrote:
> Is the following worth keeping in Lang?
>
> public Foo someJdkMethod(Object input) {
> if(input == null) {
> handleAccordingly();
> }
> return input.jdkMethod();
> }
>
> I feel that we've bloated up with these methods, and is it really
> worth it? I still have lots of if(x != null && x.callFoo()) type
> invocations, having a small handful of methods available in Lang to
> let me say if(FooUtils.callFoo(x)) isn't enough to hide all of the
> other times when I might have to worry about it.
>
> Personally I'd like to see these methods removed from Lang [especially
> given Stephen's blogging about null protected setting in some future
> JVM].
>
> An example:
>
> public static String trim(String str) {
> return str == null ? null : str.trim();
> }
>
> Given that I'm likely to do N things to the string, chances are I'll
> check for null up front and then invoke methods rather than repeatedly
> writing ugly code by using StringUtils.
>
> Any thoughts in favour of these methods?
What do bug catchers such as FindBugs do with situations like these?
Would they still report it as a potential bug? Or, do they dig into
the FooUtils.callFoo() methods to see if they're doing the null check?
I'm just curious, I guess. If FindBugs is still going to report it
as a potential bug, then it would seem like folks would probably be
doing the null check on their own to quiet down FindBugs (not that
everyone uses it of course).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org