A discussion of Scala Try (scala.util.Try)

Heather Miller recently added a new container type called Try to the Scala standard library. This is based on com.twitter.util.Try which we’ve made much productive use of at Twitter. After it was introduced, there was a minor uproar in parts of the Scala community, and discussion turned into trolling — not productive. I wanted to write about Try, its motivations, and why I (still) believe it is both useful and well-designed.

The basic idea of Try is to represent a computation that may fail, allowing the programmer to divorce exception handling from the stack. It provides a number of useful combinators (map, flatMap, rescue, handle, etc.) that enhance composition. For example, I can write a function that knows how to recover a certain kind of error, and apply it to any Try value. Just as with exceptions, if a Try fails but isn’t recovered (eg. with rescue), the computation is terminated. This allows me to write code that chains computations together, and since we use the standard naming scheme for these combinators (map, flatMap, filter) we can use Scala’s comprehension syntax ...

A quote from Victor Klang from a different URL: "Try is heap-based error handling, compared to try-catch which is stack-based error handling." (http://grokbase.com/p/gg/scala-debate/128svrykfq/design-improvement-for-success-failure)