Play Scala: exception safe way to retrieve config from play.api.Configuration

52 views
Skip to first unread message

ase...@gmail.com

unread,
Feb 13, 2017, 10:01:34 PM2/13/17
to Play Framework
Many of the configuration retrieving methods have signature with a return type of Option.

For e.g.
def getInt(path: String): Option[Int] 

I was under the impression that if Play couldn't read the config it would simply return None, but in reality it can either return Some(value), None or throw an exception! I think in the scala API it would be better much better to encode this fact in the return type itself and use a scala.util.Try

def getInt(path: String): Try[Int]


Or alternatively keep the option signature but return None if there is an error. This though means the client is not exposed to the reason why the config wasn't read, so perhaps the Try is better.

Will Sargent

unread,
Feb 13, 2017, 10:18:08 PM2/13/17
to play-fr...@googlegroups.com
play.api.Configuration does return Option[A], but you can always call "configuration.underlying" and get an instance of Config, which comes from the Typesafe Config API, and only has the value or throws exception.

--
Will Sargent
Engineer, Lightbend, Inc.


--
You received this message because you are subscribed to the Google Groups "Play Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/ffa34e5d-30cb-43f4-87ea-2d68c5806e36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Greg Methvin

unread,
Feb 13, 2017, 10:36:27 PM2/13/17
to play-framework
What kind of exceptions are you getting that you want to handle? Once you've loaded the configuration file, that would typically only happen if your configuration is malformed. The client of your app generally shouldn't be exposed to this kind of error, since that's the developer's problem.

On Mon, Feb 13, 2017 at 6:40 PM, <ase...@gmail.com> wrote:

--
You received this message because you are subscribed to the Google Groups "Play Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/ffa34e5d-30cb-43f4-87ea-2d68c5806e36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Greg Methvin
Tech Lead - Play Framework

ase...@gmail.com

unread,
Feb 14, 2017, 12:30:23 AM2/14/17
to Play Framework
The one we just hit was a case of malformed config where getInt was called when the config at that path was actually an object i.e. the path used wasn't correct.

However since many of these are just read into vals on a Class the end result of the exception was an important Singleton couldn't be created and in the end the App couldn't start as a result of failing to read a relatively unimportant config value.

We've been using config like this

private val prop:Int = configuration.getInt("mypath.to.property").getOrElse(3)

which we were perhaps incorrectly assuming was safe in that with many of these properties the fallback is fine and much preferable to failing with an exception.

I guess I can handle it on my end like in the example below, I just found it awkward that the methods throw exceptions and don't express it in the return type through Try[_]

private val prop: Int = Try {
    configuration
.getInt("mypath.to.property")
} match {
   
case Success(Some(value)) => value
   
case _ => 3
}



On Tuesday, February 14, 2017 at 2:36:27 PM UTC+11, Greg Methvin wrote:
What kind of exceptions are you getting that you want to handle? Once you've loaded the configuration file, that would typically only happen if your configuration is malformed. The client of your app generally shouldn't be exposed to this kind of error, since that's the developer's problem.
On Mon, Feb 13, 2017 at 6:40 PM, <ase...@gmail.com> wrote:
Many of the configuration retrieving methods have signature with a return type of Option.

For e.g.
def getInt(path: String): Option[Int] 

I was under the impression that if Play couldn't read the config it would simply return None, but in reality it can either return Some(value), None or throw an exception! I think in the scala API it would be better much better to encode this fact in the return type itself and use a scala.util.Try

def getInt(path: String): Try[Int]


Or alternatively keep the option signature but return None if there is an error. This though means the client is not exposed to the reason why the config wasn't read, so perhaps the Try is better.

--
You received this message because you are subscribed to the Google Groups "Play Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages