6 Dealing with optional data

This chapter explains why representing the absence of data is tricky in programs and how Kotlin encourages safer practices than relying on null pointers. It reviews the pitfalls of “business nulls” and sentinel values that silently blur intent and cause fragile code, then contrasts them with Kotlin’s nullable and non-nullable type system, which forces programmers to acknowledge and handle absence explicitly. The goal is to work with optional data in a way that avoids unchecked nulls, improves readability, and enables functional composition without scattering defensive checks.

To achieve this, the chapter develops an Option type with two cases: Some for the presence of a value and None for its absence. Building on this foundation, it introduces a small, composable toolkit: getOrElse (with eager and lazy defaults), map for transforming contained values, flatMap for chaining computations that may produce options, filter for conditional retention, and orElse for fallback options. It shows how to lift ordinary functions to operate over Option, combine multiple options with map2/map3, and adapt legacy APIs (including those that may throw exceptions). Practical examples include replacing null-returning map lookups with a getOption extension and calculating statistics like variance by composing operations that can short-circuit on missing input.

The chapter also demonstrates composing Option with List via sequence and traverse to invert List> into Option>, enabling all-or-nothing aggregation in a single pass. It closes with guidance on when to use each tool: nullable types may be fine for strictly local control flows (never to leak outside), while Option expresses truly optional data in public APIs. More generally, Option illustrates the monadic pattern—alongside List—where flatMap enables safe, declarative composition. Although many real-world absences stem from errors better modeled in richer types (introduced next), learning Option equips you with fundamental, reusable techniques for robust, null-free code.

Figure 6.1. Using an Option type for optional data allows you to compose functions even when the data is absent. Without the Option type, composing functions wouldn’t produce a function because the resulting program would potentially throw a NullPointerException.

Figure 6.2. Lifting a function

• You need a way to represent optional data, which means data that may or may not be present. The null pointer is the most impractical and dangerous way to represent the absence of data. Sentinel values and empty lists are other possible ways to represent the absence of data, but they don‘t compose well.
  
• Kotlin uses nullable types to represent optional data. It protects you against NullPointerException when you use nonnullable types, and it forces you to handle null when using nullable types.
  
• The Option data type is a much better way to represent optional data. The Some subtype represents data, and the None subtype represents the absence of data.
  

• You can apply functions to Option through the map and flatMap higher-order functions, allowing for easy Option composition.
  
• Functions operating on values can be lifted to operate on Option instances.
  
• List can be composed with Option. A List<Option> can be turned into an Option<List> using the sequence function.
  
• Option instances can be compared for equality. Instances of subtype Some are equal if their wrapped values are equal. Because there‘s only one instance of None, all instances of None are equal.
  
• Although Option may represent the result of a computation producing an exception, all information about the occurring exception is lost. In the next chapter, you‘ll learn how to deal with this problem.
  

FAQ

val x = max(list).getOrElse { expensiveFallback() }

fun <A,B,C> map2(oa: Option<A>, ob: Option<B>,
                 f: (A) -> (B) -> C): Option<C> =
  oa.flatMap { a -> ob.map { b -> f(a)(b) } }