Why is foreach better than get for Scala Options?

scala scala-option
Michael picture Michael · Jul 25, 2011 · Viewed 15.8k times · Source

Why using foreach, map, flatMap etc. are considered better than using get for Scala Options? If I useisEmpty I can call get safely.

Answer

Daniel C. Sobral picture Daniel C. Sobral · Jul 25, 2011

Well, it kind of comes back to "tell, don't ask". Consider these two lines:

if (opt.isDefined) println(opt.get)
// versus
opt foreach println

In the first case, you are looking inside opt and then reacting depending on what you see. In the second case you are just telling opt what you want done, and let it deal with it.

The first case knows too much about Option, replicates logic internal to it, is fragile and prone to errors (it can result in run-time errors, instead of compile-time errors, if written incorrectly).

Add to that, it is not composable. If you have three options, a single for comprehension takes care of them:

for {
  op1 <- opt1
  op2 <- opt2
  op3 <- opt3
} println(op1+op2+op3)

With if, things start to get messy fast.

Related questions

Check for None in Scala Option type isEmpty method

I'm using the Option Type's isEmpty method to check if there is no value. I do not want to use the case match as in my situation, I just want to check if there is None as I would throw …

Read More
Wrapping null-returning method in Java with Option in Scala?

Suppose I have a method session.get(str: String): String but you don't know whether it will return you a string or a null, because it comes from Java. Is there an easier way to treat this in Scala instead …

Read More
How to flatten list of options using higher order functions?

Using Scala 2.7.7: If I have a list of Options, I can flatten them using a for-comprehension: val listOfOptions = List(None, Some("hi"), None) listOfOptions: List[Option[java.lang.String]] = List(None, Some(hi), None) scala> for (opt <- …

Read More