1

I am really tired of doing all the if null checks, resp. I also want to have a more configurable scenario for this. Let me explain this by an example:

I have a getter() which may return null or '0' in both cases the resp. setter() should not be called passing the getter().

So the implementation is

if(getter() != null && !getter().equals('0')) setter(getter()); 

this however really anoys me, especially if getter() and setter() are really long method calls and I have to introduce helper variables for this.

I am thinking about a method with parameter

ifNotSet(getter(), setter(), new Object[null, '0']); 

which does exactly the same thing. Where the parameters to ifNotSet are

  • getter - the method to check if it does not equal one of the conditions
  • setter - the method to call in the way setter(getter) if conditions does not apply
  • conditions - the conditions which must not apply on evaluation of getter() for the method to be executed

At first sight this does not seem to complicated, it however is! Is anyone aware of a solution to this problem or any kind of implementation?

Thanks!

Update

I've been working some more on the problem, after the feedback of you guys, and found out about the following

    private boolean ns(Object[] condition, Object getter) {
    boolean ret = false;
    for (Object object : condition) {
        if(getter) equals or == ??
    }
    return true;
}

    Object[] cond = new Object[] { null, "0" };
    Object a;
if (ns(cond, a = getter()))setter(a);

Well, this seemed to be at least a solution if you have a lot of allocations to do. However, if you take a look at the ns() method... the question on the incoming conditions is, whether to use == or equals to do the comparison!?

3
  • "I am really tired of doing all the if null checks" -- have a look at Groovy and its "safe navigation" operator ("?."). groovy.codehaus.org/Operators#Operators-SafeNavigationOperator Commented Feb 27, 2013 at 9:15
  • 1
    why not make a isNullOrZero(x) method? So, if (!isNullOrZero(getter()) setter(getter()); Commented Feb 27, 2013 at 9:18
  • => Thanks to Scala for bringing getOrElse method from Option type :) ... No null object and no ugly code as Java has .. ;) Commented Feb 27, 2013 at 9:34

3 Answers 3

3

You can use this way

  public boolean checkNotNullOrZero(String s)
    {
    return (s!=null) && !s.equals("0");
    }

Basic use:

if(checkNotNullOrZero(getter()))
{
setter(getter());
}
Sign up to request clarification or add additional context in comments.

1 Comment

hmm, but this way I would have to implement a checkNotNullOrZero for each setter() I have, wouldn't I? So it's not generic at all if bot setter and getter methods change all the time!
1

You can't do what that as in Java methods are not first-class citizens. You could use reflection or anon classes but it would be way more work .

If null and zero are always equivalent for getter then could that be changed to return just one of the two?

If null and zero are always equivalent for setter then could that be changed to normalize the two?

Could you create a method isNullOrZero(x) then you can have

if (!isNullOrZero(getter())) {
  setter(getter());
}

1 Comment

same here, I would have to implement the method for each getter() which does not short-cut anything :( thx for the feedback, appreciate it!
1

Ugly way of doing this literally in Java:

public interface Getter {
    public Object get();
}

public interface Caller {
    public void call();
}

public void callIfNotNull(Getter getter, Caller caller, Object[] nullObjects) {
    Object value = getter.get();
    for(Object nullObject : nullObjects) {
        if(value==nullObject) {
            return;
        }
    }
    caller.call();
}

Usage:

callIfNotNull(new Getter() {
        @Override
        public Object get() {
            return getterMethod();
        }
    }, new Caller() {
            @Override
            public void call() {
                setter();
            }
        }, new Object[]{null, '0'});
    }

You might need to implement sane way to check for null objects and give reasonable names.

Personnaly, I wouldn't go with this approach. I would try to implement Null Object pattern to resolve an issue.

1 Comment

Much more work! I see doesn't make much sense to implement as it does not short-cut the problem :) thx however for the feedback +1 will have a look at the pattern!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.