Pattern Matching in Depth
Scala's match expression is a vastly more powerful relative of a Java or C switch statement: it can match against literal values, types, case class structure, collection shapes, and guard conditions, and -- unlike switch -- it's an expression that produces a value rather than a statement, so val result = x match { case 1 => one; case _ => other } directly assigns the matched branch's result. Because match expressions are exhaustively checked by the compiler when matching against a sealed hierarchy, pattern matching becomes both a control-flow tool and a compile-time safety net.
Cricket analogy: A match expression is like an umpire's decision tree that also returns a verdict -- instead of just branching like a switch (out or not out), matching a ball outcome to Wide or NoBall directly produces the extra-run value used in the scorecard.
Matching on Types, Case Classes, and Guards
Pattern matching can deconstruct case classes directly in the case clause, binding their fields to new names in one step: case Circle(r) if r > 10 => big circle both extracts the radius into r and adds a guard condition (if r > 10) that must also hold for that branch to match. You can also match on runtime type with case s: String => ... (which uses isInstanceOf/asInstanceOf under the hood safely), combine multiple literal patterns with | as in case yes | y => true, and bind the whole matched value to a name with case p @ Point(x, y) => ... when you need both the deconstructed fields and the original object.
Cricket analogy: case Delivery(speed, _) if speed > 145 => express pace is like a speed-gun analyst flagging deliveries -- it both extracts the speed reading and applies a guard condition, so only genuinely express deliveries from bowlers with Shoaib Akhtar-caliber pace get flagged, not every delivery.
sealed trait Shape
case class Circle(radius: Double) extends Shape
case class Rectangle(width: Double, height: Double) extends Shape
case class Triangle(base: Double, height: Double) extends Shape
def describe(shape: Shape): String = shape match {
case Circle(r) if r > 10 => s"Large circle, radius $r"
case Circle(r) => s"Circle, radius $r"
case Rectangle(w, h) if w == h => s"Square, side $w"
case Rectangle(w, h) => s"Rectangle ${w}x$h"
case Triangle(b, h) => s"Triangle, base=$b height=$h"
}
val numbers = List(1, 2, 3, 4)
numbers match {
case Nil => println("empty")
case head :: Nil => println(s"single element: $head")
case first :: second :: rest => println(s"first=$first second=$second rest=$rest")
}Matching Collections and Extractors
List patterns use the cons operator: case head :: tail => ... deconstructs a non-empty list into its first element and remaining list, case Nil => ... matches the empty list, and case first :: second :: rest => ... peels off two elements at once -- this recursive-deconstruction style is central to writing list-processing functions idiomatically in Scala. Beyond built-in collection patterns, you can write custom extractors by defining an unapply method (returning Option[T] for single-value extraction) or unapplySeq (returning Option[Seq[T]] for variable-arity extraction) on any object, letting you pattern-match against domain concepts that aren't case classes at all, such as regular expressions or custom parsing logic.
Cricket analogy: case opener :: rest => ... deconstructing a batting order is like a scorer peeling off the opening batter from the rest of the lineup -- the recursive pattern mirrors how a commentator analyzes openers vs the rest of the order one partnership at a time.
Sealed Hierarchies and Exhaustiveness
When a match expression covers a value of a sealed trait type, the Scala compiler performs exhaustiveness checking: if you forget to handle one of the sealed hierarchy's known subtypes, the compiler emits a warning (or an error, with -Xfatal-warnings enabled) at compile time rather than letting the gap surface as a scala.MatchError thrown at runtime when that unhandled case actually occurs. A wildcard case _ => ... branch technically satisfies exhaustiveness for any type, but using it on a sealed hierarchy defeats the purpose of exhaustiveness checking, since adding a new subtype later won't trigger a fresh compiler warning -- favor explicitly listing every case when the hierarchy is closed and small.
Cricket analogy: Exhaustiveness checking on sealed trait DismissalType is like the ICC auditing a scorer's dismissal-recording template before the season starts -- if Stumped is missing from the template, the audit catches it immediately, rather than the gap only being discovered when a wicketkeeper actually stumps a batter mid-match.
Because pattern matching binds new names from deconstructed values, it doubles as Scala's primary destructuring mechanism -- the same case Point(x, y) => syntax works in match, in for comprehensions, and in val Point(x, y) = somePoint value bindings.
A non-exhaustive match on a type the compiler can't fully verify (e.g., a plain non-sealed trait, or matching on Any) throws scala.MatchError at runtime for any unhandled input -- always add a case _ => fallback unless you've deliberately sealed the hierarchy and want the compiler's exhaustiveness warning.
- match is an expression that produces a value, unlike Java/C's switch statement.
- Case clauses can deconstruct case classes, bind names, add guard conditions with if, and combine literals with |.
- List patterns use :: (cons) for deconstruction and Nil for the empty list, enabling recursive list processing.
- Custom extractors implement unapply (single value) or unapplySeq (variable arity) to enable pattern matching on non-case-class types.
- Matching on a sealed trait hierarchy gets compiler exhaustiveness checking, catching missing cases before runtime.
- A wildcard case _ => satisfies exhaustiveness but silences the warning that would otherwise catch newly added subtypes.
- An unhandled case at runtime throws scala.MatchError.
Practice what you learned
1. What is the key difference between Scala's match and Java's switch?
2. What does case Circle(r) if r > 10 => ... do?
3. What does the compiler do when a match on a sealed trait misses a subtype?
4. What happens at runtime if a non-exhaustive match encounters an unhandled value?
5. What must a custom extractor implement to support matching against a single extracted value?
Was this page helpful?
You May Also Like
Case Classes Explained
Understand what case class generates for free -- structural equality, copy, and pattern matching support -- and how pairing it with sealed traits builds safe, exhaustiveness-checked data models.
Traits in Scala
Learn how Scala traits provide composable, disciplined multiple inheritance, how linearization resolves overriding conflicts, and when to reach for a trait versus an abstract class.
Option and Null Safety
Learn how Scala's Option[T] replaces null with a compiler-checked container type, covering map/flatMap/getOrElse, for-comprehensions, and safe Java interop.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics