0

I have a simple piece of code:

txtRequiredDate.setText(wwDateFormatter.format(todoEntity.getRequiredDate()));
txtRequiredDateDay.setText(dayOfWeek(todoEntity.getRequiredDate()));
txtDoneDate.setText(wwDateFormatter.format(todoEntity.getDoneDate()));
txtDoneDateDay.setText(dayOfWeek(todoEntity.getDoneDate()));

Problem is that sometimes the date is null (as it is optional to fill out). In those cases, the wwDateFormatter triggers a NullPointerException.

One way of fixing it, as I see it is:

if (todoEntity.getRequiredDate() != null) 
{
    txtRequiredDate.setText(wwDateFormatter.format(todoEntity.getRequiredDate()));
    txtRequiredDateDay.setText(dayOfWeek(todoEntity.getRequiredDate()));
}

if (todoEntity.getDoneDate() != null)
{
    txtDoneDate.setText(wwDateFormatter.format(todoEntity.getDoneDate()));
    txtDoneDateDay.setText(dayOfWeek(todoEntity.getDoneDate()));
}

But I was wondering if there is a more concise way of writing the above statement?

Thank You!

Edit I guess it's not that this isn't optimized, but rather the fact that I'd like to learn various ways of checking for nulls, especially if situation ever arises that I must have 30 of those statements, heh.

Metal Wing
  • 525
  • 1
  • 11
  • 22

3 Answers3

3

Why not wrap the formatter with a null-aware variant that returns an empty string if passed a null ?

You may also be interested in the Null Object Pattern. Also note this blog, which discusses Scala's Option pattern and the equivalent in Java. These are both very useful patterns that you can make use of to mitigate your issue above.

Brian Agnew
  • 268,207
  • 37
  • 334
  • 440
2

Make sure your date strings are never null (use an empty string: "" instead) - no more ifs needed.

Or you could use a non-null utility method (similar to what Brian suggested):

private String nonNull(String s) {
    return (s == null ? "" : s);
}

public void yourMethod() {
    txtRequiredDate.setText(wwDateFormatter.format(nonNull(todoEntity.getRequiredDate())));
    txtRequiredDateDay.setText(dayOfWeek(nonNull(todoEntity.getRequiredDate())));
    ...
}
assylias
  • 321,522
  • 82
  • 660
  • 783
  • But then down the road he might have to be checking for empty strings. What if null is really the correct value to have by default? – carmenism Jun 26 '12 at 13:44
  • empty strings won't create NPEs... I am just saying that it is easier to not allow null as a default value when possible. – assylias Jun 26 '12 at 13:45
2

This is a typical reason why accessors/properties are good to avoid if possible. Try to get rid of exposing the entity's "raw" data and put the logic inside the entity itself - then you have your null check in one place.

txtRequiredDate.setText(todoEntity.formattedRequiredDate())

...where you do your null check in the entity method instead (and returning empty string or whatever if null).

Whether getters and setters really are evil or not, old classic article in this subject, is up for debate, but at least having encapsulation in mind when designing entities is a good thing IMO.

Roger
  • 1,944
  • 1
  • 11
  • 17
  • I actually like this idea in my case! Although I am not 100% sure of how correct that would be, it seems logical to me! – Metal Wing Jun 26 '12 at 14:10