A project I am working on has the following piece code:
val ftr1: Future[Try[(Date, String)]] = Future {
if (someCondition) {
// some code
val amazonClient = Try[new com.amazonaws.services.s3.AmazonS3Client(...)]
amazonClient.map { c =>
// doing some stuff
(new Date, "SomeString")
}
} else {
// some code
Failure(new Exception)
}
}
Future.firstCompletedOf(Seq(ftr1, anotherFuture)) map {
case t: Try[(Date, String)] => {
t match {
case Success(r) => //do some things
case _ => //do some another things
}
case _ => //do some another things
}
So, during compiling I have following warning:
[warn] non-variable type argument java.util.Date in type pattern java.util.Date, String) is unchecked since it is eliminated by erasure
and
[warn] case t: (Date, String) => //do some things
And I actually do not understand, what these warnings mean and how can this code be refactored in order to get rid of these warnings?
Try[+T] is an abstract class, one which you can't create an instance of.
There are two case classes which inherit from it, Success and Failure, which you should really be using.
The compiler is warning you that at compile time, type erasure is going to erase those types, thus matching on them isn't going to get you the results you want. More on that can be found in How do I get around type erasure on Scala? Or, why can't I get the type parameter of my collections?
But, you can avoid all this completely if you simply match on Success and Failure to reduce the unnecessary nesting in your match:
val ftr1: Future[Try[(Date, String)]] = Future {
if (someCondition) {
// some code
val amazonClient = Try { /* stuff */ }
amazonClient.map { c =>
// doing some stuff
(new Date, "SomeString")
} else Failure(new Exception)
}
Future.firstCompletedOf(Seq(ftr1, anotherFuture)) map {
case Success((date, myString)) => /* do stuff */
case Failure(e) => log(e)
}
Related
A bit new to scala, sort of confused at the type definitions here and how to resolve it.
private def getContract(organizationId: String, sc: SecurityContext): Future[Contract] = {
val configRequest = ConfigsActor.ReadConfigRequest(CONFIG_KEY, Option(organizationId))(sc)
(configActor ? configRequest).mapTo[Config] andThen {
case Success(config) =>
JsonUtil.extract[Contract](config.data)
case otherwise =>
log.warning("some unknown case has happened", otherwise)
}
}
I would expect the akka ask to return the result, map it to a Config. In my andThen clause to convert it into a Contract type and return it.
but I get a type mismatch
[error]
[error] found : scala.concurrent.Future[com.example.service.Config]
[error] required: scala.concurrent.Future[com.example.service.Contract]
[error] (configActor ? configRequest).mapTo[Config] andThen
[error]
Future#andThen is designed to execute a side-effect without transforming the value inside the future. To transform the value inside the Future simply map over the future
(configActor ? configRequest).mapTo[Config] map { config =>
JsonUtil.extract[Contract](config.data)
} andThen { case Failure(e) => log.warning("some unknown case has happened", e) }
The following is worth remembering
someFuture
.map { value => /* transform value */ }
.recover { error => /* transform error */ }
.andThen { /* execute side-effect */
case Success(value) => logger.info("Successfully ...")
case Failure(error) => logger.error("Failed to ...", error)
}
You can think of andThen as tap for Futures.
I have the following code:
var tempLastFileCreated: File = try {
files(0)
} catch {
case e: ArrayIndexOutOfBoundsException => ???
}
where files is val files: Array[File] = dir.listFiles()
Now whatever I give in case e I get the message Expression of type Unit doesn't conform to expected type File
I understand that the right hand part of the => has to be something which is of type File.
Can anyone tell me what to put there?
You are promising that tempLastFileCreated is a File, therefore it cannot also be a Unit or a String, etc. You have a couple options. You could use a Option[File] instead:
val tempLastFileCreated: Option[File] = try {
Some(files(0))
}
catch {
case e: ArrayIndexOutOfBoundsException => None
}
Or if you wanted to store an error message, for example, another option is to use Either:
val tempLastFileCreated: Either[String, File] = try {
Right(files(0))
}
catch {
case e: ArrayIndexOutOfBoundsException => Left("index out of bounds!")
}
Whatever bests suits your needs. You might want to take a look at Scala's scala.util.Try data type, which is safer. For example,
val tempLastFileCreated: Option[File] = Try(files(0)) match {
case Success(file) => Some(file)
case Failure(throwable) => None //or whatever
}
I'm catching an UndefinedBehaviorError thrown by the bad asInstanceOf in my code like this:
$("button").on(
"click",
".showDialog",
(event: JQueryEventObject) => {
event.preventDefault()
val helpText = "Enter any number"
js.Dynamic.global.swal(
JC(
title = helpText,
text = helpText,
`type` = "input",
showCancelButton = true,
closeOnConfirm = false,
inputPlaceholder = helpText
),
(input: Any) => {
try {
input.asInstanceOf[Boolean]
} catch {
case _: Throwable =>
try {
val correctInput = input.asInstanceOf[String].toDouble
global.console.log("success")
} catch {
case _: Throwable =>
js.Dynamic.global.swal.showInputError("Incorrect data!")
}
}
}
)
}
)
It works fine with fastOptJS but fails with fullOptJS. How to correctly rewrite this code to run it with fullOptJS or what are the other options?
In Scala.js, a bad cast does not reliably throw a ClassCastException, unlike in Scala/JVM. Instead, a bad cast is an undefined behavior, as specified here. This means that in fullOpt, the program can behave arbitrarily, and in particular is allowed not in throw. In fastOpt, however, the compiler is kind and reliably throws, but not a ClassCastException (as it would give a false sense of security), rather an UndefinedBehaviorError.
UndefinedBehaviorErrors must never be caught, as catching one hides a bug which will surface in fullOpt. This is your mistake here: you are catching that UndefinedBehaviorError under case _: Throwable =>. Note that catching Throwable is bad practice in Scala. Instead, you should be using case scala.util.control.NonFatal(_) =>. A NonFatal handler does not catch UndefinedBehaviorError, and would therefore not hide the bug.
Now to solve your issue, you simply not use asInstanceOf as a means to type-test. Even on Scala/JVM, that code would be super bad practice. Use pattern matching instead:
(input: Any) => {
def reportIncorrectData(): Unit =
js.Dynamic.global.swal.showInputError("Incorrect data!")
input match {
case input: Boolean =>
// Here, input is a Boolean
input
case input: String =>
// Here, it is a String; let's try to convert it to Double
try {
val correctInput = input.toDouble
} catch {
case _: NumberFormatException =>
reportIncorrectData()
}
case _ =>
// It is something else, always incorrect data
reportIncorrectData()
}
}
In a non-functional language, I might do something like:
try {
// some stuff
} catch Exception ex {
return false;
}
// Do more stuff
return true;
In Scala, however, this pattern is clearly not correct. If my scala code looks like this:
try {
// do some stuff
}
catch {
case e: Exception => // I want to get out of here and return false
)
}
// do more stuff
true
How do I properly do that? I don't want to use the "return" statement, of course, but I also don't want to drop through and "do more stuff" and eventually return true.
You want to represent a computation that can either succeed or signal that an error has occurred. That's the perfect use case for the Try monad.
import scala.util.{ Try, Success, Failure }
def myMethod: Try[Something] = Try {
// do stuff
// do more stuff
// if any exception occurs here, it gets wrapped into a Failure(e)
}
So you're returning a Try instead of a Bool, which is infinitely more clear and idiomatic.
Usage example:
myMethod match {
case Success(x) => println(s"computation succeded with result $x")
case Failure(e) => println(s"computation failed with exception $e.getMessage")
}
If you don't even care about the exception, but you just want to return a value in case of success, you can even convert the Try to an Option.
def myMethod: Option[Something] = Try {
// do stuff
// do more stuff
// return something
// if any exception occurs here, it gets wrapped into a Failure(e)
}.toOption
myMethod match {
case Some(x) => println(s"computation succeded with result $x")
case None => println("computation failed")
}
To respond to the question in the comments, you can do
Try {
// do stuff
} match {
case Failure(_) => false
case Success(_) =>
// do more stuff
// true
}
although I would suggest to return something more meaningful than a Boolean, whenever it makes sense.
Of course this can be nested
Try {
// do stuff
} match {
case Failure(_) => false
case Success(_) =>
// do more stuff
Try {
// something that can throw
} match {
case Failure(_) => false
case Success(_) =>
// do more stuff
true
}
}
but you should consider putting the Try chunks into separate functions (returning a Try).
Ultimately, we can take advantage of the fact that Try is a monad, and do something like this
Try { /* java code */ }.flatMap { _ =>
// do more stuff
Try { /* java code */ }.flatMap { _ =>
// do more stuff
Try { /* java code */ }
}
} match {
case Failure(_) => false // in case any of the Try blocks has thrown an Exception
case Success(_) => true // everything went smooth
}
scala> def f() = try { ??? ; 1 } catch { case _: Throwable => 2 }
f: ()Int
scala> f()
res2: Int = 2
scala> import util._
import util._
scala> def g() = Try { ??? ; 1 } recover { case _ => 2 } get
warning: there was one feature warning; re-run with -feature for details
g: ()Int
scala> g()
res3: Int = 2
HTH. Small functions helps.
Another hint:
scala> def j() = Try (1) map (_ + 42) recover { case _ => 2 } get
warning: there was one feature warning; re-run with -feature for details
j: ()Int
scala> j()
res4: Int = 43
try-catch expression is not good for functional programming.
Anyway, an easy solution that still uses try-catch:
val result = try {
// do some stuff
Some(/* The final expression */)
}
catch {
case e: Exception => // Do something or nothing
None
}
result match {
case Some(r) => // Do something with r
true
case None => false
}
You can use scala.util.Try for cleaner and more functional-styled code.
Refer to https://codereview.stackexchange.com/questions/38689/code-with-many-early-returns-exits-into-the-functional-style
I faced a similar problem like you, but the answer in the Stackexchange CodeReview helped me a lot.
Successful or erroneous cases can be represented by several Scala type.
If you consider the error in the meaning of "something is missing" (e.g. file not found), you can use Option[T] (e.g. Option[File]), with case values None or Some(T). Then orElse, getOrElse or fold and map/flatMap functions can be used to dispatch cased.
You can also use Either[E, T], with (by convention), in Left(E) case the error value (e.g. a String as error message), and in Right(T) successful T value.
Monads Try[T] or Future[T] can be used in the same way.
In the field of I/O, the very nice scala-arm lib provide type ManagedResource[T] that wrap either successful (T) or erroneous (List[Throwable]]) result of computation based on resources.
Valudation types in Scalaz are also useful for such cases.
'util.Try{ do some stuff }.isSuccess'
Very often i end up with lots of nested .map and .getOrElse when validating several consecutives conditions
for example:
def save() = CORSAction { request =>
request.body.asJson.map { json =>
json.asOpt[Feature].map { feature =>
MaxEntitiyValidator.checkMaxEntitiesFeature(feature).map { rs =>
feature.save.map { feature =>
Ok(toJson(feature.update).toString)
}.getOrElse {
BadRequest(toJson(
Error(status = BAD_REQUEST, message = "Error creating feature entity")
))
}
}.getOrElse {
BadRequest(toJson(
Error(status = BAD_REQUEST, message = "You have already reached the limit of feature.")
))
}
}.getOrElse {
BadRequest(toJson(
Error(status = BAD_REQUEST, message = "Invalid feature entity")
))
}
}.getOrElse {
BadRequest(toJson(
Error(status = BAD_REQUEST, message = "Expecting JSON data")
))
}
}
You get the idea
I just wanted to know if there's some idiomatic way to keep it more clear
If you hadn't had to return a different message for the None case this would be an ideal use-case for for comprehension. In your case , you probably want to use the Validation monad, as the one you can find in Scalaz. Example ( http://scalaz.github.com/scalaz/scalaz-2.9.0-1-6.0/doc.sxr/scalaz/Validation.scala.html ).
In functional programming, you should not throw exceptions but let functions which can fail return an Either[A,B], where by convention A is the type of result in case of failure and B is the type of result in case of success. You can then match against Left(a) or Right(b) to handle, reespectively, the two cases.
You can think of the Validation monad as an extended Either[A,B] where applying subsequent functions to a Validation will either yield a result, or the first failure in the execution chain.
sealed trait Validation[+E, +A] {
import Scalaz._
def map[B](f: A => B): Validation[E, B] = this match {
case Success(a) => Success(f(a))
case Failure(e) => Failure(e)
}
def foreach[U](f: A => U): Unit = this match {
case Success(a) => f(a)
case Failure(e) =>
}
def flatMap[EE >: E, B](f: A => Validation[EE, B]): Validation[EE, B] = this match {
case Success(a) => f(a)
case Failure(e) => Failure(e)
}
def either : Either[E, A] = this match {
case Success(a) => Right(a)
case Failure(e) => Left(e)
}
def isSuccess : Boolean = this match {
case Success(_) => true
case Failure(_) => false
}
def isFailure : Boolean = !isSuccess
def toOption : Option[A] = this match {
case Success(a) => Some(a)
case Failure(_) => None
}
}
final case class Success[E, A](a: A) extends Validation[E, A]
final case class Failure[E, A](e: E) extends Validation[E, A]
Your code now can be refactored by using the Validation monad into three validation layers. You should basically replace your map with a validation like the following:
def jsonValidation(request:Request):Validation[BadRequest,String] = request.asJson match {
case None => Failure(BadRequest(toJson(
Error(status = BAD_REQUEST, message = "Expecting JSON data")
)
case Some(data) => Success(data)
}
def featureValidation(validatedJson:Validation[BadRequest,String]): Validation[BadRequest,Feature] = {
validatedJson.flatMap {
json=> json.asOpt[Feature] match {
case Some(feature)=> Success(feature)
case None => Failure( BadRequest(toJson(
Error(status = BAD_REQUEST, message = "Invalid feature entity")
)))
}
}
}
And then you chain them like the following featureValidation(jsonValidation(request))
This is a classic example of where using a monad can clean up your code. For example you could use Lift's Box, which is not tied to Lift in any way. Then your code would look something like this:
requestBox.flatMap(asJSON).flatMap(asFeature).flatMap(doSomethingWithFeature)
where asJson is a Function from a request to a Box[JSON] and asFeature is a function from a Feature to some other Box. The box can contain either a value, in which case flatMap calls the function with that value, or it can be an instance of Failure and in that case flatMap does not call the function passed to it.
If you had posted some example code that compiles, I could have posted an answer that compiles.
I tried this to see if pattern matching offered someway to adapt the submitted code sample (in style, if not literally) to something more coherent.
object MyClass {
case class Result(val datum: String)
case class Ok(val _datum: String) extends Result(_datum)
case class BadRequest(_datum: String) extends Result(_datum)
case class A {}
case class B(val a: Option[A])
case class C(val b: Option[B])
case class D(val c: Option[C])
def matcher(op: Option[D]) = {
(op,
op.getOrElse(D(None)).c,
op.getOrElse(D(None)).c.getOrElse(C(None)).b,
op.getOrElse(D(None)).c.getOrElse(C(None)).b.getOrElse(B(None)).a
) match {
case (Some(d), Some(c), Some(b), Some(a)) => Ok("Woo Hoo!")
case (Some(d), Some(c), Some(b), None) => BadRequest("Missing A")
case (Some(d), Some(c), None, None) => BadRequest("Missing B")
case (Some(d), None, None, None) => BadRequest("Missing C")
case (None, None, None, None) => BadRequest("Missing D")
case _ => BadRequest("Egads")
}
}
}
Clearly there are ways to write this more optimally; this is left as an exercise for the reader.
I agree with Edmondo suggestion of using for comprehension but not with the part about using a validation library (At least not anymore given the new features added to scala standard lib since 2012). From my experience with scala, dev that struggle to come up with nice statement with the standard lib will also end up doing the same of even worst when using libs like cats or scalaz. Maybe not at the same place, but ideally we would solve the issue rather than just moving it.
Here is your code rewritten with for comprehension and either that is part of scala standard lib :
def save() = CORSAction { request =>
// Helper to generate the error
def badRequest(message: String) = Error(status = BAD_REQUEST, message)
//Actual validation
val updateEither = for {
json <- request.body.asJson.toRight(badRequest("Expecting JSON data"))
feature <- json.asOpt[Feature].toRight(badRequest("Invalid feature entity"))
rs <- MaxEntitiyValidator
.checkMaxEntitiesFeature(feature)
.toRight(badRequest("You have already reached the limit"))
} yield toJson(feature.update).toString
// Turn the either into an OK/BadRequest
featureEither match {
case Right(update) => Ok(update)
case Left(error) => BadRequest(toJson(error))
}
}
Explanations
Error handling
I'm not sure how much you know about either but they are pretty similar in behaviour as Validation presented by Edmondo or Try object from the scala library. Main difference between those object regard their capability and behaviour with errors, but beside that they all can be mapped and flat mapped the same way.
You can also see that I use toRight to immediately convert the option into Either instead of doing it at the end. I see that java dev have the reflex to throw exception as far as they physically can, but they mostly do so because the try catch mechanism is unwieldy: in case of success, to get data out of a try block you either need to return them or put them in a variable initialized to null out of the block. But this is not the case is scala: you can map a try or an either, so in general, you get a more legible code if you turn results into error representation as soon as have identified it as they are identified as incorrect.
For comprehension
I also know that dev discovering scala are often quite puzzled by for comprehension. This is quite understandable as in most other language, for is only used for iteration over collections while is scala, it seem to use usable on a lot of unrelated types. In scala for is actually more nicer way to call the function flatMap. The compiler may decide to optimize it with map or foreach but it remain correct assume that you will get a flatMap behavior when you use for.
Calling flatMap on a collection will behave like the for each would in other language, so scala for may be used like a standard for when dealing with collection. But you can also use it on any other type of object that provide an implementation for flatMap with the correct signature. If your OK/BadRequest also implement the flatMap, you may be able to use in directly in the for comprehension instead of usong an intermediate Either representation.
For the people are not at ease with using for on anything that do not look like a collection, here is is how the function would look like if explicitly using flatMap instead of for :
def save() = CORSAction { request =>
def badRequest(message: String) = Error(status = BAD_REQUEST, message)
val updateEither = request.body.asJson.toRight(badRequest("Expecting JSON data"))
.flatMap { json =>
json
.asOpt[Feature]
.toRight(badRequest("Invalid feature entity"))
}
.flatMap { feature =>
MaxEntitiyValidator
.checkMaxEntitiesFeature(feature)
.map(_ => feature)
.toRight(badRequest("You have already reached the limit"))
}
.map { rs =>
toJson(feature.update).toString
}
featureEither match {
case Right(update) => Ok(update)
case Left(error) => BadRequest(toJson(error))
}
}
Note that in term of parameter scope, for behave live if the function where nested, not chained.
Conclusion
I think that more than not using the right framework or the right language feature, the main issue with the code your provided is how errors are dealt with. In general, you should not write error paths as after thought that you pile up at the end of the method. If you can deal with the error immediately as they occur, that allow you to move to something else. On the contrary, the more you push them back, the more you will have code with inextricable nesting. They are actually a materialization of all the pending error cases that scala expect you to deal with at some point.