Type Members

1.  final class ChainingOps[A] extends AnyVal

   Adds chaining methods tap and pipe to every type.

2.  trait ChainingSyntax extends AnyRef
3.  class DynamicVariable[T] extends AnyRef

   DynamicVariables provide a binding mechanism where the current value is found through dynamic scope, but where access to the variable itself is resolved through static scope.

   DynamicVariables provide a binding mechanism where the current value is found through dynamic scope, but where access to the variable itself is resolved through static scope.

   The current value can be retrieved with the value method. New values should be pushed using the withValue method. Values pushed via withValue only stay valid while the withValue's second argument, a parameterless closure, executes. When the second argument finishes, the variable reverts to the previous value.

   someDynamicVariable.withValue(newValue) {
     // ... code called in here that calls value ...
     // ... will be given back the newValue ...
   }

   Each thread gets its own stack of bindings. When a new thread is created, the DynamicVariable gets a copy of the stack of bindings from the parent thread, and from then on the bindings for the new thread are independent of those for the original thread.

4.  sealed abstract class Either[+A, +B] extends Product with Serializable

   Represents a value of one of two possible types (a disjoint union).

   Represents a value of one of two possible types (a disjoint union). An instance of Either is an instance of either scala.util.Left or scala.util.Right.

   A common use of Either is as an alternative to scala.Option for dealing with possibly missing values. In this usage, scala.None is replaced with a scala.util.Left which can contain useful information. scala.util.Right takes the place of scala.Some. Convention dictates that Left is used for failure and Right is used for success.

   For example, you could use Either[String, Int] to indicate whether a received input is a String or an Int.

   import scala.io.StdIn._
   val in = readLine("Type Either a string or an Int: ")
   val result: Either[String,Int] =
     try Right(in.toInt)
     catch {
       case e: NumberFormatException => Left(in)
     }
   
   result match {
     case Right(x) => s"You passed me the Int: $x, which I will increment. $x + 1 = ${x+1}"
     case Left(x)  => s"You passed me the String: $x"
   }

   Either is right-biased, which means that Right is assumed to be the default case to operate on. If it is Left, operations like map and flatMap return the Left value unchanged:

   def doubled(i: Int) = i * 2
   Right(42).map(doubled) // Right(84)
   Left(42).map(doubled)  // Left(42)

   Since Either defines the methods map and flatMap, it can also be used in for comprehensions:

   val right1 = Right(1)   : Right[Double, Int]
   val right2 = Right(2)
   val right3 = Right(3)
   val left23 = Left(23.0) : Left[Double, Int]
   val left42 = Left(42.0)
   
   for {
     x <- right1
     y <- right2
     z <- right3
   } yield x + y + z // Right(6)
   
   for {
     x <- right1
     y <- right2
     z <- left23
   } yield x + y + z // Left(23.0)
   
   for {
     x <- right1
     y <- left23
     z <- right2
   } yield x + y + z // Left(23.0)
   
   // Guard expressions are not supported:
   for {
     i <- right1
     if i > 0
   } yield i
   // error: value withFilter is not a member of Right[Double,Int]
   
   // Similarly, refutable patterns are not supported:
   for (x: Int <- right1) yield x
   // error: value withFilter is not a member of Right[Double,Int]
   
   // To use a filtered value, convert to an Option first,
   // which drops the Left case, as None contains no value:
   for {
     i <- right1.toOption
     if i > 0
   } yield i

   Since for comprehensions use map and flatMap, the types of function parameters used in the expression must be inferred. These types are constrained by the Either values. In particular, because of right-biasing, Left values may require an explicit type argument for type parameter B, the right value. Otherwise, it might be inferred as Nothing.

   for {
     x <- left23
     y <- right1
     z <- left42  // type at this position: Either[Double, Nothing]
   } yield x + y + z
   //            ^
   // error: ambiguous reference to overloaded definition,
   // both method + in class Int of type (x: Char)Int
   // and  method + in class Int of type (x: Byte)Int
   // match argument types (Nothing)
   
   for (x <- right2 ; y <- left23) yield x + y  // Left(23.0)
   for (x <- right2 ; y <- left42) yield x + y  // error
   
   for {
     x <- right1
     y <- left42  // type at this position: Either[Double, Nothing]
     z <- left23
   } yield x + y + z
   // Left(42.0), but unexpectedly a `Either[Double,String]`

5.  final case class Failure[+T](exception: Throwable) extends Try[T] with Product with Serializable
6.  final case class Left[+A, +B](value: A) extends Either[A, B] with Product with Serializable

   The left side of the disjoint union, as opposed to the scala.util.Right side.

7.  class Random extends Serializable
8.  final case class Right[+A, +B](value: B) extends Either[A, B] with Product with Serializable

   The right side of the disjoint union, as opposed to the scala.util.Left side.

9.  final case class Success[+T](value: T) extends Try[T] with Product with Serializable
10.  sealed abstract class Try[+T] extends Product with Serializable

    The Try type represents a computation that may fail during evaluation by raising an exception.

    The Try type represents a computation that may fail during evaluation by raising an exception. It holds either a successfully computed value or the exception that was thrown. This is similar to the scala.util.Either type, but with different semantics.

    Instances of Try[T] are an instance of either scala.util.Success[T] or scala.util.Failure[T].

    For example, consider a computation that performs division on user-defined input. Try can reduce or eliminate the need for explicit exception handling in all of the places where an exception might be thrown.

    Example:

    import scala.io.StdIn
    import scala.util.{Try, Success, Failure}
    
    def divide: Try[Int] = {
      val dividend = Try(StdIn.readLine("Enter an Int that you'd like to divide:\n").toInt)
      val divisor = Try(StdIn.readLine("Enter an Int that you'd like to divide by:\n").toInt)
      val problem = dividend.flatMap(x => divisor.map(y => x/y))
      problem match {
        case Success(v) =>
          println("Result of " + dividend.get + "/"+ divisor.get +" is: " + v)
          Success(v)
        case Failure(e) =>
          println("You must've divided by zero or entered something that's not an Int. Try again!")
          println("Info from the exception: " + e.getMessage)
          divide
      }
    }

    An important property of Try shown in the above example is its ability to pipeline, or chain, operations, catching exceptions along the way. The flatMap and map combinators in the above example each essentially pass off either their successfully completed value, wrapped in the Success type for it to be further operated upon by the next combinator in the chain, or the exception wrapped in the Failure type usually to be simply passed on down the chain. Combinators such as recover and recoverWith are designed to provide some type of default behavior in the case of failure.

    Note: only non-fatal exceptions are caught by the combinators on Try (see scala.util.control.NonFatal). Serious system errors, on the other hand, will be thrown.

    Note:: all Try combinators will catch exceptions and return failure unless otherwise specified in the documentation.