Config

This method uses [[ConfigResolveOptions#defaults]], there is
another variant
resolve(ConfigResolveOptions)
which lets you specify non-default options.

A given [[Config]] must be resolved before using it to retrieve
config values, but ideally should be resolved one time for your entire
stack of fallbacks (see [[Config#withFallback]]). Otherwise, some
substitutions that could have resolved with all fallbacks available may
not resolve, which will be potentially confusing for your application's
users.

resolve should be invoked on root config objects, rather
than on a subtree (a subtree is the result of something like
config.getConfig("foo")). The problem with
resolve on a subtree is that substitutions are relative to
the root of the config and the subtree will have no way to get values
from the root. For example, if you did
config.getConfig("foo").resolve on the below config file,
it would not work:

{{{
common-value = 10
foo {
whatever = ${common-value}
}
}}}

Many methods on [[ConfigFactory]] such as
ConfigFactory.load() automatically resolve the
loaded Config on the loaded stack of config files.

Resolving an already-resolved config is a harmless no-op, but again, it
is best to resolve an entire stack of fallbacks (such as all your config
files combined) rather than resolving each one individually.

Note that this method does NOT look in this instance for substitution
values. If you want to do that, you could either merge this instance into
your value source using [[Config#withFallback]], or you could resolve
multiple times with multiple sources (using
[[ConfigResolveOptions#setAllowUnresolved]] so the partial
resolves don't fail).

Using this method is always optional, since you can "fail late" instead.

You must restrict validation to paths you "own" (those whose meaning are
defined by your code module). If you validate globally, you may trigger
errors about paths that happen to be in the config but have nothing to do
with your module. It's best to allow the modules owning those paths to
validate them. Also, if every module validates only its own stuff, there
isn't as much redundant work being done.

If no paths are specified in checkValid's parameter list,
validation is for the entire config.

If you specify paths that are not in the reference config, those paths
are ignored. (There's nothing to validate.)

Here's what validation involves:

-
Some changes in type from the reference config to this config will cause
an exception to be thrown. Not all potential type problems are detected,
in particular it's assumed that strings are compatible with everything
except objects and lists. This is because string types are often "really"
some other type (system properties always start out as strings, or a
string like "5ms" could be used with
getDuration(String)).
Also, it's allowed to set any type to null or override null with any type.

-
Any unresolved substitutions in this config will cause a validation
failure; both the reference config and this config should be resolved
before validation. If the reference config is unresolved, it's a bug in
the caller of this method.

If you want to allow a certain setting to have a flexible type (or
otherwise want validation to be looser for some settings), you could
either remove the problematic setting from the reference config provided
to this method, or you could intercept the validation exception and
screen out certain problems. Of course, this will only work if all other
callers of this method are careful to restrict validation to their own
paths, as they should be.

If validation fails, the thrown exception contains a list of all problems
found. See [[ConfigException.ValidationFailed#problems]]. The
exception's getMessage will have all the problems
concatenated into one huge string, as well.

Again, checkValid can't guess every domain-specific way a
setting can be invalid, so some problems may arise later when attempting
to use the config. checkValid is limited to reporting
generic, but common, problems such as missing settings and blatant type
incompatibilities.

If a path exists according to [[#hasPath]], then
[[#getValue]] will never throw an exception. However, the
typed getters, such as [[#getInt]], will still throw if the
value is not convertible to the requested type.

Note that path expressions have a syntax and sometimes require quoting
(see ConfigUtil$.joinPath and [[ConfigUtil#splitPath]]).

To handle all three cases (unset, null, and a non-null value)
the code might look like:
{{{
if (config.hasPathOrNull(path)) {
if (config.getIsNull(path)) {
// handle null setting
} else {
// get and use non-null setting
}
} else {
// handle entirely unset path
}
}}}

However, the usual thing is to allow entirely unset
paths to be a bug that throws an exception (because you set
a default in your reference.conf), so in that
case it's OK to call [[#getIsNull]] without
checking hasPathOrNull first.

Note that path expressions have a syntax and sometimes require quoting
(see ConfigUtil$.joinPath and [[ConfigUtil#splitPath]]).

Entries contain path expressions meaning there may be quoting
and escaping involved. Parse path expressions with
[[ConfigUtil#splitPath]].

Because a Config is conceptually a single-level map from
paths to values, there will not be any [[ConfigObject]] values in the
entries (that is, all entries represent leaf nodes). Use
[[ConfigObject]] rather than Config if you want a tree.
(OK, this is a slight lie: Config entries may contain
[[ConfigList]] and the lists may contain objects. But no objects are
directly included as entry values.)

Note that path expressions have a syntax and sometimes require quoting
(see ConfigUtil$.joinPath and [[ConfigUtil#splitPath]]).

Note that path expressions have a syntax and sometimes require quoting
(see ConfigUtil$.joinPath and [[ConfigUtil#splitPath]]).

Note that path expressions have a syntax and sometimes require quoting
(see ConfigUtil$.joinPath and [[ConfigUtil#splitPath]]).

Note that path expressions have a syntax and sometimes require quoting
(see ConfigUtil$.joinPath and [[ConfigUtil#splitPath]]).

Note that path expressions have a syntax and sometimes require quoting
(see ConfigUtil$.joinPath and [[ConfigUtil#splitPath]]).