# Sealed classes in Kotlin

DevFeed: [Sealed classes in Kotlin](<https://devfeed.tech/articles/sealed-classes-in-kotlin-23690.md>)

Original publisher: [Read original article](<https://medium.com/betclic-tech/sealed-classes-in-kotlin-74b1d28aaef2?source=rss----7e406d68d94b---4>)

Author: Florian Garcia

Published: 2022-09-26T13:51:32Z

Content type: tutorial

Language: en

Sources: [betclic-tech - Medium](<https://devfeed.tech/sources/betclic-tech-medium.md>)

Topics: [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [interfaces](<https://devfeed.tech/topics/interfaces.md>), [Inheritance](<https://devfeed.tech/topics/inheritance.md>), [Code](<https://devfeed.tech/topics/code.md>), [Exception](<https://devfeed.tech/topics/exception.md>)

Tags: [classes](<https://devfeed.tech/tags/classes.md>), [code](<https://devfeed.tech/tags/code.md>), [exception](<https://devfeed.tech/tags/exception.md>), [inheritance](<https://devfeed.tech/tags/inheritance.md>), [interfaces](<https://devfeed.tech/tags/interfaces.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [sealed](<https://devfeed.tech/tags/sealed.md>), [sealed-classes](<https://devfeed.tech/tags/sealed-classes.md>)

## AI overview

A tutorial explaining how Kotlin sealed classes and interfaces represent restricted class hierarchies. It shows how they help the compiler identify all supported cases and avoid missing-case handling when the hierarchy changes.

## Source excerpt

In this article, we will talk about sealed classes and interfaces. What they are, what problem they solve and how we can leverage this in real life. The problem Let's take the following code: https://medium.com/media/f1f04b5ee8f0bfc98d41cad1fbd803a2/href Our code only handles two types of animals (cats and dogs). But the compiled code does not know that only those two types exist. This means we have to add this ugly else block in our when. This can be a real issue because you start to think about what to do in a situation that shouldn't exist but that will potentially exist in the future. For instance, say that tomorrow we add cows to the list of supported animals, the code will compile just fine because we have put the else block. We could change the else part to throw an exception but Kotlin does not have checked exceptions (so it's easy to forget to catch one), and thus we end up with runtime exceptions. That's a bit sad because we probably want to know at compile time that we need to handle this new case. Solution As you probably have guessed, the solution is sealed classes or interfaces. But what are they? From the Kotlin documentation: Sealed classes and interfaces represent restricted class hierarchies that provide more control over inheritance. All direct subclasses of a sealed class are known at compile time. No other subclasses may appear after a module with the sealed class is compiled. For example, third-party clients can't extend your sealed class in their code. Thus, each instance of a sealed class has a type from a limited set that is known when this class is compiled. If rephrased, this means that we can define a bounded hierarchy. One of the important things to know when working with sealed classes is that you cannot instantiate the sealed class; thus only the leaves of the structure exist at runtime (but you can use the interface as a type). When we develop applications that are not libraries, it is pretty rare to allow an abstract class / interfac