When you start working with Futures
and similar objects collectively called "functors" or "monads", depending on their capabilities, (check out this guide on functors with amazing animated pictures) you are working with containers, boxes with special properties, and you don't want to "get the value" out of them unless strictly necessary. In the case of Future
the container represent a value calculated asynchronously.
This means that you should be working with map
,flatMap
and similar methods to use the result of the computation. This way you can keep the whole computation asynchronous. As well, the other functions in your code should return Futures and should carry them along as much as you can. Here is the Scala docs overview on Future
At the same time if you assign a Future
to a variable you're assigning the "Future container" to the variable, not the value that the Future
will contain. That's why you can't print finalResult
in your second example.
For instance, you can try:
def doSomething(value: String): Unit = ???
def calculateSomething(value: String): Boolean = ???
def calculateSomethingElse(value: Boolean): Future[Int] = ???
def myCode(...): Future[Int] = {
someCallThatReturnsFutureOfString(...)
.map { result =>
logger.info(s"Result is... $result")
// More computations with result
doSomething(result)
calculateSomething(result)
}
.flatMap { someCalculationResult =>
// More computations....
calculateSomethingElse(result)
}
}
If you want to deal with Exceptions, as I think you want to, this other answer is what you're looking for because transform
allows you to manipulate the succesful result as well as the exception.
futureResult transform {
case Success(result) =>
println(s"Result is... $result")
// More computations with result
Success(calculateSomething(result))
case f @ Failure(exception) =>
exception.printStackTrace()
f
}
I know, I sound like I'm not answering your question. You might be thinking "Hey, I want to get the value out and use it somewhere else, this guy is not telling me that" but unless specific situations that's not how they are meant to be used. Switching to this way of thinking requires effort and it's not easy to "see how it shold be done" at the beginning.
If you still want to get the value out, then Vincent's answer is a good one.