From 621817470483ea73a40ceadc9885dd1984fb057b Mon Sep 17 00:00:00 2001 From: Havoc Pennington Date: Sat, 3 May 2014 09:59:42 -0400 Subject: [PATCH] Settings pattern is not a way to get an optional setting --- README.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index e5b4927e..4bdba455 100644 --- a/README.md +++ b/README.md @@ -317,18 +317,19 @@ options: `Config`; `ConfigObject` implements `java.util.Map` and the `get()` method on `Map` returns null for missing keys. See the API docs for more detail on `Config` vs. `ConfigObject`. - 6. Consider the "Settings class" pattern with `checkValid()` to - verify that you have all settings when you initialize the - app. See the [Schemas and Validation](#schemas-and-validation) - section of this README for more details. - + The *recommended* path (for most cases, in most apps) is that you require all settings to be present in either `reference.conf` or `application.conf` and allow `ConfigException.Missing` to be thrown if they are not. That's the design intent of the `Config` API design. -If you do need a setting to be optional, checking `hasPath()` in +Consider the "Settings class" pattern with `checkValid()` to +verify that you have all settings when you initialize the +app. See the [Schemas and Validation](#schemas-and-validation) +section of this README for more details on this pattern. + +**If you do need a setting to be optional**: checking `hasPath()` in advance should be the same amount of code (in Java) as checking for `null` afterward, without the risk of `NullPointerException` when you forget. In Scala, you could write an enrichment class