Examples of com.typesafe.config.Config.checkValid()

• com.typesafe.config.Config.checkValid()
  Validates this config against a reference config, throwing an exception if it is invalid. The purpose of this method is to "fail early" with a comprehensive list of problems; in general, anything this method can find would be detected later when trying to use the config, but it's often more user-friendly to fail right away when loading the config.

  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:

  • All paths found in the reference config must be present in this config or an exception will be thrown.
  • 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 {@link #getMilliseconds}). 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 {@link 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. @param reference a reference configuration @param restrictToPaths only validate values underneath these paths that your code module owns and understands @throws ConfigException.ValidationFailed if there are any validation issues @throws ConfigException.NotResolved if this config is not resolved @throws ConfigException.BugOrBroken if the reference config is unresolved or caller otherwise misuses the API