# Handle NullValueInNestedPathException

I am looking for a elegant solution to this. I am new to Spring framework. I have a method:

public String getStringProperty(String property) {
Object value = SomeWrapper.getPropertyValue(property);
return (value != null) ? String.valueOf(value) : "";
}


The immediate upstream method is:

public String getValueForHeader(String header) {
}


Where LOOKUP_TABLE is an ImmutableMap (google guava). An example representation of it:

private final ImmutableMap<String, String> LOOKUP_TABLE = ImmutableMap.<String, String>builder()
.build();


So, when I call getStringProperty method with property "Person.billing.contact.primary.email" I get a "" String. My aim here is to return empty String when some property does not exist. For example if "Person.billing.contact.primary.email" does not have "email" set in address an empty String is returned. Now if "contact" or "primary" is not set I would get a NullValueInNestedPathException but I should return an empty String.

One way to deal with this is to introduce the try catch lock in this method and have the catch block return empty string.

public String getStringProperty(String property) {
try {
Object value = transactionWrapper.getPropertyValue(property);
return (value != null) ? String.valueOf(value) : "";
} catch (NullValueInNestedPathException e) {
return "";
LOGGER.error("Invalid property {} ", property);
return "!invalid property!";
}
}


The NotReadablePropertyException is to warn me when I am trying to get some property which does not exist (or getter for that property is not readable).

The other solution could be to throw same exception and let methods upstream worry.

Is there some alternative, elegant way to handle this inside my getStringProperty() method ?

Returning "" is reasonable, since that is what you want to use as the default value.

Returning the special value "!invalid property!" to indicate an error might be allowable only in the following limited circumstance:

• This is view-layer code, not your model, not middleware, not an API, and
• You actually want that special string to appear in the UI as a placeholder, and
• The placeholder text is to be presented in the normal font and color.

If any of those conditions is not applicable, then the special string is absolutely inappropriate. That is precisely what exceptions are for — exceptional cases. If you present exceptional cases as if they were legitimate data, then you end up with bugs like this one, where a person whose name is Null causes grief.

• Thanks! In my case I require the place holder text to be present for some of my Learning algorithms upstream. Apr 26 '15 at 15:34
• That doesn't sound like a legitimate reason. Apr 26 '15 at 18:10
• Sorry for the confusion, I need the text "!invalid property!" in my output file. I would probably be running this code on a secure server, where I have restricted access to logs. Based on my output file, I would know if the underlying object structures have changed. Is this a good practice or did I mess up the concept ? Apr 26 '15 at 22:29
• If you actually need that exact string to appear in the output as if it were legitimate data, then this is a reasonable implementation. That still doesn't make it good practice to use "!invalid text!" as a special string to indicate failure, though. You should either use a separate error-indication field or an escaping mechanism to ensure that bare ! never appears in normal text. Apr 26 '15 at 22:53