Missing configuration option retrieval should return null rather than throw exception

Hi.

Currently there is no mechanism to check if property exists, only to fetch it (and, probasbly, raise an exception). Since underlying exception is not a checked one, it’s terribly easy to miss, and (from my point of view) any map-like structures should return null on missing values to keep code consistent. So basically i suggest to:

• Add mechanism to check property presence (i.e. hasProperty(String key))
• Add mechanism to return default value in case there is no property set (i.e. getProperty(String key, Class<T> type, T defaultValue))
• Don’t throw exception whenever target property is not found, just return null; add getRequiredProperty(String key, Class<T> type) method that will throw exception if property is not found

[norbertpotocki]

Hi @etki,

That’s a valid concern. Here’s what my approach to this problem has been so far.

Assumption: Your code should always know what settings you defined.

If the property is missing that means something went seriously wrong and thus an exception is being thrown. I see the following scenarios (and how to handle them) when you could run into this problem. I’m curious what your use case is. Is it one of the following or something else?

• different configurations for different environments (e.g. test env uses a username/password combo to access a db and prod env uses a certificate instead) -> this can be modeled by having two different interfaces defined and bound accordingly
• removing deprecated configuration value -> you deploy a code change that doesn’t use this setting anymore and than you remove the value
• default values -> this is already supported - see this article, section “Configuration defaults”

That said I see that such feature is a nice to have and I’m already working on it and should be able to ship it soon. Here’s the initial design. Let me know what are your thoughts on this. The initial design is as follows:

• Add hasProperty(String key) method as you suggested
• Extend getProperty(String key, Class<T> type) to support optionals. Then you will be able to use it as follows:

Optional<String> possiblyMissingSetting = getProperty("myProperty",  new GenericType<Optional<Integer>>() { });); 

and via interface binding

interface Config {
  Optional<String> possiblyMissingSetting;
}

[magnayn]

So, we just got bitten by this - an interface bound to an environment config provider happily returned null, but bind it to a consulprovider, and the absence caused an exception. This was made worse by the fact that this new, optional, parameter was being applied against old configuration as it made no sense to update it as nothing had changed.

My problem with the assumption “Your code should always know what settings you defined.” is that “If the property is missing that means something went seriously wrong and thus an exception is being thrown” does not follow.

The former is stated through the interface contract. Java is a nullable language. An interface defining

public interface Preferences {
String myPreference();
}

Implies that NULL is a perfectly semantically valid return type from that interface - and for most K/V stores, the only way of recording NULL is through their complete absence.

Now being able to wrap that in Optional.absent() sounds great - as would supporting @Notnull type annotations to enhance that contract, but throwing an exception on absence feels like a defect to me.