introduced a ValueError that represents an error caused by a config value that isn't the expected type

[ppurang]

Ideally the error message should also carry the information of the type expected. But that would mean somehow accessing type information on any 'A'.

[stew]

@ppurang This looks like a nice change, so thanks!

The one concern I have is that this introduces an incompatibility with earlier versions, since you are introducing a new Exception that could be thrown.

Imagine that someone has code:

try {
  cfg.require[String]("test.immutable.value.error")).
} catch {
  case KeyError(name) => 
     // express a default
}

They now have to introduce a new exception handler to transform the same set of inputs identically.

So I like this change, but I think that we need to introduce a version bump to 3.11.x with it.

[ppurang]

@stew I agree with you - this is an incompatibility eventhough we never explicitly define the exceptions we raise.

I hope everyone does something more appropriate to make the API less "exceptional" like:

Maybe.fromTryCatchThrowable(
                cfg.require[String]("test.immutable.value.error")
           )
           .getOrElse("default")

Another thing bothers me even more. The previous PR that was accepted and has been released might break dependent code even more. Because of an issue we were pulling in all system properties given a prefix. Example:

//before the present version

//all system properties become part of cfg
val cfg = load(List(Required(SysPropsResource(Prefix("user")))))  
val path = cfg.require[String]("path.separator")  // found 

//present version

//only system properties begining with 'user' become part of cfg
val cfg = loadConfig(Required(SystemProperties(Prefix("user"))))
val path = cfg.require[String]("path.separator")  // not found! 

Thanks for looking into the PR.

[timperrett]

Included in #51