Option(null).getOrElse(“Value to display in case of ‘null’”)

Option.apply is defined in the same way as Matt’s single-argument Nvl.apply method above.

It sounds like what you want is an easy way to handle nulls that are returned from Java or from a poorly written Scala function. I don’t know of anything built-in that does this, but here’s a simple object you can use (named in honor of the NVL function from SQL which serves a similar purpose).

scala>object Nvl {
| def apply[T](ref: T, alt: T) =
| if (ref == null) alt else ref
| def apply[T](ref: T) =
| if (ref == null) None else Some(ref)
| }
defined module Nvl

scala> Nvl(“non-null string”)
res0: Option[java.lang.String] = Some(non-null string)

scala> Nvl(null)
res1: Option[Null] = None

scala> Nvl(“original”, “alternate”)
res2: java.lang.String = original

scala> Nvl(null, “alternate”)
res3: java.lang.String = alternate

I’m thinking of something like

Some(null).getOrElse(“Value to display in case of ‘null’”)

^^^^
NOT WORKING CODE

There are better idioms for using Option than the ones I knew about when I wrote this post. But using Option efficiently and readably takes study and practice. For example, it’s not obvious from flatMap’s signature that your example code will work. You have to have read the Option object’s source code to know about the implicit conversion to Iterable. (Perhaps a list of implicit conversions provided by the companion object should appear in a class’s scaladoc?)

Java desensitizes you to nulls. Nulls are an integral part of standard APIs in Java. Take a line like “while (reader.readLine() != null)” for example. Just as the beginning Java programmer would happily use goto and pointer arithmetic if he could but eventually comes to understand he’s better off without them, so should the Scala programmer learn to avoid null. A null is just a NullPointerException waiting to happen.

So I agree that returning an Option is better than returning a null. Heck, if Scala one day replaces Java altogether I’d like to see null deprecated. However, I still prefer a design that avoids Option when possible. For example:

def even(n: Int): Boolean = n%2 == 0

def getEven(l: List[Int]): List[Int] = l filter even

To me, it’s more readable than the solution using Option.

Besides, you can do stuff with Option. For instance:

def even(n: Int): Option[Int] = if (n % 2 == 0) Some(n) else None

def getEven(l: List[Int]): List[Int] = l flatMap even

Did you see any “match”?

A lot of “all those match blocks” are usually not necessary. Option has a number of useful methods, and much of the time does whatever your match block would do.

The code example, for instance:
| getAStringMaybe(num) match {
| case Some(str) => println(str)
| case None => println(“No string!”)
| }
could be written as
println(getAStringMaybe(num).get(“No string!”))
which can’t be said to be very verbose :-)

See also http://www.scala-lang.org/docu/files/ScalaOverview.pdf on page three for a class diagram.