Why `scala.util.Try` is not mentioned in chapter "Handling errors without exceptions" of book "functional programming in Scala"? -

in chapter "handling errors without exceptions" of book "functional programming in scala", author gives:

1. the problem of throwing exceptions body of function
2. use option if don't care actual exception
3. use either if care actual exception

but scala.util.try not mentioned. point of view, think try suitable when care actual exception, why it's not mentioned? there reason have missed?

i'm neither of authors of functional programming in scala, can make few guesses why don't mention try.

some people don't standard library's try because claim it violates functor composition law. think position kind of silly, reasons josh suereth mentions in comments of si-6284, debate highlight important aspect of try's design.

try's map , flatmap explicitly designed work functions may throw exceptions. people fpis school of thought (including me) tend suggest wrapping such functions (if absolutely have deal them @ all) in safe versions @ low level in program, , exposing api never throw (non-fatal) exceptions.

including try in api muddles layers in model—you're guaranteeing api methods won't throw exceptions, you're handing people type that's designed used functions throw exceptions.

that's complaint standard library's design , implementation of try, though. it's easy enough imagine version of try different semantics, map , flatmap methods didn't catch exceptions, , there still reasons avoid "improved" version of try whenever possible.

one of these reasons using either[myexceptiontype, a] instead of try[a] makes possible more mileage out of compiler's exhaustivity checking. suppose i'm using following simple adt errors in application:

sealed class fooapperror(message: string) extends exception(message)  case class invalidinput(message: string) extends fooapperror(message) case class missingfield(fieldname: string) extends fooapperror(   s"$fieldname field missing" ) 

now i'm trying decide whether method can only fail in 1 of these 2 ways should return either[fooapperror, a] or try[a]. choosing try[a] means we're throwing away information that's potentially useful both human users , compiler. suppose write method this:

def dosomething(result: either[fooapperror, string]) = result match {   case right(x) => x   case left(missingfield(_)) => "bad" } 

i'll nice compile-time warning telling me match not exhaustive. if add case missing error, warning goes away.

if had used try[string] instead, i'd exhaustivity checking, way rid of warning have catch-all case—it's not possible enumerate throwables in pattern match.

sometimes can't conveniently limit kinds of ways operation can fail our own failure type (like fooapperror above), , in these cases can use either[throwable, a]. scalaz's task, example, wrapper future[throwable \/ a]. difference either (or \/) supports kind of signature, while try requires it. , it's not want, reasons useful exhaustivity checking.