By the end, you’ll have a solid understanding of how to leverage sealed classes to write more robust and maintainable code.
Sealed class in Kotlin allows developers to create a restricted class hierarchy. Unlike regular classes, sealed classes can only be subclassed within the same package where they are declared. This ensures that all possible subclasses are known at compile-time, providing better type safety and exhaustiveness checks when dealing with class hierarchies.
A sealed class is declared using the sealed keyword, and its subclasses are typically defined as either classes or
objects within the same file. This setup helps in representing a fixed set of possible types, similar to enums but with
the flexibility of classes. For example, sealed classes are particularly useful in scenarios where you have a
limited set of operations that can be performed, and you want to enforce this restriction throughout your codebase.
1
2
3
4
sealed class Shape
class Circle(val radius: Double) : Shape()
class Rectangle(val width: Double, val height: Double) : Shape()
object Unknown : Shape()
In this example, Shape is a sealed class with three possible types: Circle, Rectangle, and a singleton object Unknown.
The compiler knows all possible subclasses of Shape, enabling it to perform exhaustive checks e.g. when you use a when
expression to handle different shapes, you can be sure all cases are covered, or the compiler will warn you if you miss any.
Sealed classes thus provide a way to model complex data structures while maintaining type safety and ensuring your code is robust and less prone to errors. They strike a balance between the simplicity of enums and the flexibility of class inheritance, making them a useful tool in every Kotlin developer’s toolbox.
Enums are suitable for representing a fixed set of constants, but they lack the flexibility of sealed classes. Enums cannot have properties or methods specific to each constant, whereas sealed classes allow each subclass to have its own properties and methods. This makes sealed classes more versatile for modeling complex data structures. However, enums are simpler and more concise when you only need to represent a small, fixed set of values without additional behavior.
Sealed classes offer several advantages that make them an attractive choice for developers. Firstly, they provide exhaustive when expressions.
Because all subclasses of a sealed class are known at compile-time, the compiler can enforce that all possible cases are handled.
This reduces the likelihood of runtime errors and makes the code more robust.
Another advantage is improved readability and maintainability. Sealed classes allow you to define a clear and constrained hierarchy, making it easier to understand the possible types and their relationships. This can significantly reduce the cognitive load on developers, as they do not need to consider unknown subclasses scattered across the codebase. All possible subclasses are defined in one package, providing a clear and concise overview.
Sealed classes also enhance type safety. By restricting the set of subclasses, sealed classes ensure that you can only work with a known set of types. This reduces the risk of type-related bugs and makes the code easier to reason about. For instance, if you add a new subclass, the compiler will alert you to update all relevant expressions, ensuring that your code remains consistent and correct.
Furthermore, sealed classes can encapsulate state and behavior more effectively than enums. While enums are useful for representing a fixed set of constants, sealed classes offer more flexibility by allowing each subclass to have its own properties and methods. This makes sealed classes ideal for modeling complex data structures and domain-specific logic.
Imagine you’re building a data-fetching function that could either succeed or fail. With sealed classes, you can create a clean, type-safe representation of these outcomes.
We’ll define a Result sealed class with two subclasses: Success and Error. The Success class will hold the
successfully fetched data, while the Error class will contain information about what went wrong.
1
2
3
4
sealed class Result<out T> {
data class Success<out T>(val data: T) : Result<T>()
data class Error(val reason: String) : Result<Nothing>()
}
This setup allows you to return a Result object from your functions, ensuring that calling code must handle
both success and failure cases. It’s a compile-time guarantee that you won’t forget to deal with errors.
Using this Result type, you can write functions that clearly express their potential outcomes:
1
2
3
4
5
fun fetchUser(id: String) = try {
Success(getUser(id))
} catch (e: Exception) {
Error("Failed to fetch user: ${e.message}")
}
When using this function, you’re forced to handle both cases, leading to more robust code:
1
2
3
4
when (val result = fetchUser("123")) {
is Success -> displayUser(result.data)
is Error -> showErrorMessage(result.reason)
}
This pattern promotes cleaner, more maintainable code by making error handling explicit and encouraging developers to consider all possible outcomes. It’s a prime example of how Kotlin’s sealed classes can improve code quality and reduce bugs related to unexpected states or unhandled errors.
Sealed classes in Kotlin prove invaluable when modeling system commands, especially in scenarios where you need to represent a finite set of operations. Let’s explore how we can use sealed classes to create a robust command structure for a hypothetical file system manager.
Imagine you’re building a file system utility that needs to handle various operations like creating directories, deleting files, and moving items. Each of these commands might require different parameters and behave uniquely. Sealed classes offer a neat solution to model these diverse yet related commands.
Here’s how you might structure your system commands:
1
2
3
4
5
6
sealed class FileSystemCommand {
data class CreateDirectory(val path: String) : FileSystemCommand()
data class DeleteFile(val path: String) : FileSystemCommand()
data class MoveItem(val sourcePath: String, val destinationPath: String) : FileSystemCommand()
object ListContents : FileSystemCommand()
}
This structure provides several benefits. First, it ensures type safety – you can only create commands that are explicitly defined. Second, it allows you to use Kotlin’s when expression to handle each command type exhaustively, preventing oversight of any command type.
You can then create a command processor that handles these commands:
1
2
3
4
5
6
fun processCommand(command: FileSystemCommand) = when (command) {
is CreateDirectory -> createDir(command.path)
is DeleteFile -> deleteFile(command.path)
is MoveItem -> moveItem(command.sourcePath, command.destinationPath)
is ListContents -> listContents()
}
This approach offers clear advantages in terms of code organization and maintainability. As your system grows, you can easily add new command types without modifying existing code, adhering to the open-closed principle. It also provides a clear interface for other parts of your application to interact with the file system operations, enhancing modularity and testability.
To get the most out of sealed classes in Kotlin, it’s essential to follow best practices that ensure your code is clean, maintainable, and efficient.
This enforces the restriction that sealed classes provide and ensures the compiler can perform exhaustive checks. Although you can define sealed classes in a package defining them in one file improves readability by keeping the related types together.
Sealed classes are ideal for scenarios where you have a well-defined set of possible types. Use them to model state machines, command patterns, or any situation where the set of types is fixed and known at compile-time.
whenTake advantage of the compiler’s ability to check for exhaustiveness in when expressions.
1
2
3
4
5
fun describeShape(shape: Shape) = when (shape) {
is Circle -> "Circle with radius ${shape.radius}"
is Rectangle -> "Rectangle with width ${shape.width} and height ${shape.height}"
Unknown -> "Unknown Shape"
}
Ensure that all possible subclasses are handled, either by explicitly listing them or using the else branch for completeness.
This reduces the risk of runtime errors and makes your code more robust.
While sealed classes are powerful, they are not always the best solution. Avoid overusing them in situations where other class types, such as enums, interfaces, or abstract classes, might be more appropriate. Use sealed classes when the benefits of type safety and controlled hierarchies are most relevant.
Sealed classes are a powerful feature in Kotlin that provide a way to represent restricted class hierarchies with enhanced type safety and maintainability. By allowing only a fixed set of subclasses, sealed classes enable exhaustive expressions and improve code readability. They are particularly useful for modeling state machines, algebraic data types, and complex states. By understanding and implementing sealed classes effectively, you can leverage their advantages to create robust and maintainable Kotlin applications. Embrace sealed classes in your Kotlin projects to ensure a more structured and error-resistant codebase.
]]>In this comprehensive guide, we’ll dive deep into Kotlin data classes, exploring their features, benefits, and best practices. We’ll cover from basic usage to advanced techniques, helping you use the full power of this fundamental Kotlin feature.
A data class is a class specifically designed to hold data rather than behavior. These classes automatically generate
substantial boilerplate code that you would otherwise have to write yourself. This includes methods like toString(), equals(),
hashCode(), and copy().
To declare a data class you use the data keyword before the class definition. Here’s the basic syntax:
1
data class Person(val name: String, var age: Int)
Notice that you may define immutable (preferred, defined with val) as well as mutable (var) properties.
Kotlin’s data classes come with several very useful features:
Data classes automatically provide implementations for:
toString() for readable string representationequals() for structural equality comparisonhashCode() for consistent hash code generationcopy() for easy creation of modified instancesHaving those methods generated ensures consistent and correct implementation as well as reduces boilerplate.
Data classes significantly reduce boilerplate code. A single line can replace many lines in other languages:
1
data class Product(val id: Int, val name: String, val price: Double)
Additionally, to concise syntax making code more clean and understandable, it makes the intent of the class (to hold data) immediately clear.
Data classes support component functions (componentN()), allowing easy destructuring:
1
val (name, age) = Person("Alice", 25)
The syntax enables easy unpacking of object properties, which can enhance readability in certain situations.
Data classes can be made immutable by using ‘val’ for properties:
1
data class ImmutablePerson(val name: String, val age: Int)
Data classes are final, but they can extend classes or implement interfaces
1
2
interface Printable
data class Report(val title: String) : Printable
The above features make data classes in Kotlin powerful tools for creating simple, efficient, and functional data-holding objects with minimal code.
While Kotlin generates most of the boilerplate code, you can still customize the behavior of data classes by overriding the generated methods. For example:
1
2
3
4
5
data class Person(val name: String, val age: Int) {
override fun toString(): String {
return "Person's name is $name and age is $age"
}
}
Kotlin allows you to provide default values for properties and use named arguments, making the creation of instances more flexible:
1
2
3
4
5
data class Person(val name: String = "Unknown", val age: Int = 0)
println(Person()) // Prints "Person(name=Unknown, age=0)"
println(Person(name = "Alice")) // Prints "Person(name=Alice, age=0)"
println(Person(age = 25)) // Prints "Person(name=Unknown, age=25)"
Sealed classes and data classes can be used together to represent complex data hierarchies. A sealed class restricts the hierarchy to a limited set of subclasses, which can be data classes:
1
2
3
4
5
6
7
8
9
10
11
12
13
sealed class Shape {
data class Circle(val radius: Double) : Shape()
data class Rectangle(val width: Double, val height: Double) : Shape()
data class Square(val side: Double) : Shape()
}
fun describeShape(shape: Shape) = when (shape) {
is Circle -> "Circle with radius ${shape.radius}"
is Rectangle -> "Rectangle with width ${shape.width} and height ${shape.height}"
is Square -> "Square with side ${shape.side}"
}
println(describeShape(Square(12.0))) // Prints "Square with side 12.0"
Although data classes allow defining mutable properties (using var), they can lead to unexpected behavior and bugs as
described in Explicit Mutability post. Whenever possible,
use val to declare properties in data classes to make them immutable. This ensures that the state of the object
cannot be changed after it is created, promoting safer and more predictable code.
Data classes are intended to hold data, so avoid including complex logic within them. Keep them focused on representing the state and use other classes or functions to handle the behavior.
Destructuring declarations can simplify your code when you need to extract properties from a data class instance. Use them to enhance readability and reduce boilerplate.
While data classes are convenient, avoid creating excessively large data classes with many properties. This can make the class difficult to manage and understand. Consider breaking it down into smaller, more focused classes.
Kotlin’s data classes are a powerful feature that significantly reduces boilerplate code and simplifies the development process. They are designed to hold data and automatically generate useful methods, promoting immutability and providing a clean, expressive syntax. By leveraging data classes in your Kotlin applications, you can write more concise, readable, and maintainable code. Following best practices and understanding the common pitfalls, you help can harness the full potential of Kotlin data classes and improve the quality of your codebase.
]]>An extension function is a way to add a new function to a class from outside of it. This means you can extend the functionality of classes you don’t own or can’t modify (including classes from the standard library as well as third-party libraries).
The basic syntax for an extension function is:
1
fun Receiver.functionName() {}
Here, Receiver is the type you’re extending, and functionName is the name of your new function.
Using extension functions offer many benefits but here are some to consider:
You might be wondering why use extension functions instead of just adding a member function to the class? There are several reasons:
It’s important to note though that extension functions are resolved statically. They don’t actually modify the class they extend, and they can’t access private members of the class.
Let’s start with some simple examples to illustrate how extension functions work:
1
2
fun String.exclaim() = "$this!"
println("Hello".exclaim()) // Prints "Hello!"
In this example we have added a new function exclaim() to the existing String class. We can now call this function on any String instance.
You can also define extensions functions with parameters (same as with standard functions):
1
2
3
fun Int.isMultipleOf(number: Int) = this % number == 0
println(12.isMultipleOf(3))// Prints "true"
println(12.isMultipleOf(5))// Prints "false"
Kotlin’s null safety is one of its fundamental features as we explored in Null Safety post, and it works seamlessly with extension functions. You can define extension functions on nullable types:
1
2
3
fun String?.orEmpty() = this ?: ""
val someValue: String? = null
println(someValue.orEmpty())
This is particularly useful for providing default behaviors for null values.
In addition to functions, Kotlin also allows you to define extension properties:
1
2
3
4
val String.lastChar: Char
get() = this[length - 1]
println("Kotlin".lastChar) // Outputs: n
You can even extend companion objects, allowing you to add methods to classes or interfaces:
1
2
3
4
5
6
7
class MyClass {
companion object
}
fun MyClass.Companion.greeting() = "Hello from companion object extension"
println(MyClass.greeting())
This can be useful for adding utility functions that are related to a class but don’t need an instance of the class.
Extension functions can also be generic, allowing you to write more flexible and reusable code:
1
2
3
4
5
fun <T> T.println() = println(this)
5.println() // Outputs: 5
"Hello".println() // Outputs: Hello
listOf(1, 2, 3).println() // Outputs: [1, 2, 3]
This example defines a println() extension function that works on any type.
It is also possible to define extension functions with infix notation which, in certain situations, can lead to more readable code:
1
2
infix fun Int.isMultipleOf(number: Int) = this % number == 0
println(10 isMultipleOf 5) // Outputs: true
The infix keyword allows you to call the function using infix notation (without the dot and parentheses).
Here are some common use case examples for using extension functions.
Extension functions are often used in creating domain-specific languages (DSLs) in Kotlin.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
class Html private constructor() {
companion object {
fun html(fn: Html.() -> Unit) =
Html().apply(fn).render()
}
private var content: String = ""
internal fun append(value: String) {
content += value
}
fun render() = "<html>$content</html>"
}
class Body {
private var content: String = ""
internal fun append(value: String) {
content += value
}
internal fun render() = "<body>$content</body>"
}
fun Html.body(fn: Body.() -> Unit) = append(Body().apply(fn).render())
fun Body.p(text: String) = append("<p>$text</p>")
fun Body.a(href: String, text: String) = append("<a href='$href'>$text</a>")
This example demonstrates how extension functions can be used to create a DSL for HTML generation.
Adding utility functions for common string operations.
1
2
3
fun String.removeFirstAndLast() = substring(1, length - 1)
println("Hello".removeFirstAndLast()) // Outputs: ell
Adding custom operations to collections.
1
2
3
4
fun <T> List<T>.secondOrNull(): T? = if (size < 2) null else this[1]
println(listOf(1, 2, 3).secondOrNull()) // Outputs: 2
println(listOf(1).secondOrNull()) // Outputs: null
Kotlin’s standard library makes extensive use of extension functions. Some examples include:
let, apply, run, with, and also for scoping and object manipulationforEach, map, filter, etc., for collectionslast, substring and other various string manipulation functionsUnderstanding these can help you write more idiomatic Kotlin code and make better use of the language’s features.
While extension functions are very powerful, here are some best practices and limitations to keep in mind:
Extension functions are a powerful feature in Kotlin that can significantly enhance code readability, organization, and reusability. They allow developers to extend existing classes with new functionality without modifying their source code, which is particularly useful when working with classes from external libraries or the standard library.
By using extension functions and following best practices, you can create more expressive and maintainable code. They’re particularly useful for utility functions, DSL creation, and adding convenience methods to existing types.
As with any powerful feature, it’s important to use extension functions thoughtfully. When used well, they can make your Kotlin code more concise, readable, and enjoyable to work with.
Whether you’re new to Kotlin or an experienced developer, mastering extension functions can significantly improve your coding skills and help you write more elegant and efficient code.
]]>val and var keywords, provides developers with fine-grained control over data mutability.
In this blog post we’ll explore the ins and outs of explicit mutability in Kotlin, its benefits, best practices, and highlight briefly how it compares to other languages.
Before we dive into Kotlin’s approach, let’s briefly discuss what mutability means in programming. In simple terms mutability refers to the ability to change or modify data after it’s been created. Mutable data can be altered, while immutable data remains constant throughout its lifetime.
Kotlin has two keywords for variable declaration: val and var. These keywords explicitly define whether a variable or field is immutable (val) or mutable (var).
final keyword in Java. For example:
1
2
val name = "Alice"
// name = "Bob" // Compilation error
1
2
var age = 25
age = 26 // This is perfectly valid
By using val and var, you’re making your intentions clear to your future self and other developers. Anyone reading the code can immediately understand whether a variable is meant to be changed or not.
Using ‘val’ for variables that shouldn’t change helps prevent accidental modifications. The compiler will catch any attempts to reassign a ‘val’ variable, reducing the risk of unintended side effects.
Immutable data is inherently thread-safe. When you’re working with concurrent code, using immutable data wherever possible can help avoid race conditions and other concurrency issues.
Kotlin supports some of the functional programming concepts, and the use of immutable data aligns well with functional programming principles. It encourages writing pure functions and promotes easier reasoning about code behavior and state mutations.
It’s important to understand that ‘val’ creates a read-only reference, which is not always the same as true immutability. Let’s explore this concept further:
When you use ‘val’ with a mutable object, the reference is immutable, but the object’s internal state can still be modified.
1
2
3
val list = mutableListOf(1, 2, 3)
list.add(4) // This is valid, as we're modifying the list's content, not the reference
// list = mutableListOf(5, 6) // This would be a compilation error
In the example above the list reference is read only byt list itself is mutable.
Kotlin’s smart cast feature works with ‘val’ declarations but not with ‘var’.
1
2
3
4
5
6
var mutableVar: Any = ""
fun failingSmartCastOfVar() {
if (mutableVar is String) {
print(mutableVar.length) // Compilation failure
}
}
The example above will fail to compile because the compiler can guarantee that a ‘val’ reference won’t change between the type check and its usage.
When declaring properties in a class, ‘val’ creates a read-only property with a generated getter, while ‘var’ creates a mutable property with both a getter and a setter.
1
2
3
4
class Person(
val name: String, // Read-only property (has a getter)
var age: Int // Mutable property (has both getter and setter)
)
Start by declaring all variables with ‘val’. Only change to ‘var’ if you need to reassign the variable later. This approach, known as “immutability by default,” helps create more predictable and maintainable code.
When you do need mutable state, use ‘var’. But try to limit the scope of mutable variables as much as possible. Consider if you can make the variable local to a function instead of a class property.
Kotlin provides both mutable and immutable versions of collections.
1
2
val immutableList = listOf(1, 2, 3)
val mutableList = mutableListOf(1, 2, 3)
Prefer using immutable collections (List, Set, Map) over their mutable counterparts (MutableList, MutableSet, MutableMap) when the collection doesn’t need to be modified. Use mutable collections in limited scope and not return them, e.g. only in the body of the function but convert to immutable before returning.
Additionally Kotlin offers a concise and efficient way to create immutable collections using builder functions buildXXX. Those higher-order functions allow you to construct collections using a mutable builders within its lambda, providing a clean syntax for adding elements conditionally or in loops. The resulting collection is immutable, e.g:
1
2
3
4
5
buildList {
for (i in 0..10) {
add(i)
}
}
Collection builder functions are particularly useful when you need to create complex collections based on certain logic or transformations, without the verbosity of creating a mutable collections and converting it afterward.
When creating data classes, consider making properties ‘val’ by default. If you need mutable properties, you can always use ‘var’, but immutable data classes are easier to work with and reason about.
1
2
3
4
5
data class User(
val id: Int,
val name: String,
var lastLoginDate: Date
)
For top-level or object declarations that are known at compile-time, use ‘const val’. This creates a true compile-time constant, which can be more efficient.
1
2
3
object Constants {
const val MAX_COUNT = 100
}
Sometimes you might want to expose a read-only property while keeping a mutable backing field. Kotlin allows this through backing properties:
1
2
3
4
5
6
7
8
9
class Counter {
private var _count = 0
val count get() = _count
fun increment() {
_count++
}
}
Kotlin’s property delegation allows you to reuse common property patterns. You can create a read-only property that is calculated on-demand using ‘by lazy’:
1
2
3
4
5
val expensiveComputation: Int by lazy {
println("Computing...")
// Complex computation here
42
}
Sometimes you need to have a non-null var property that’s initialized after the constructor. Kotlin provides the lateinit modifier for this:
1
2
3
4
5
6
7
8
9
10
11
12
13
class MyTest {
lateinit var subject: String
@BeforeTest
fun setup() {
subject = "Some value"
}
@Test
fun testLength() {
assertEquals(subject.length, 10)
}
}
Kotlin’s inline value classes are a great way to create type-safe wrappers with zero runtime overhead. These type of class can be used to wrap domain values and inherently immutable:
1
2
3
4
5
6
7
8
9
@JvmInline
value class Password(
val value: String
)
@Test
fun `example inline class test`() {
assertEquals(Password("secret").value, "secret")
}
While Kotlin’s explicit mutability is a great feature, it’s not come without some challenges:
Developers coming from languages without explicit mutability might need time to adjust to thinking about mutability for every variable they declare.
Using var excessively can lead to code that is difficult to understand and maintain. To avoid this, always consider if a variable truly needs to be mutable and try to refactor your code to use val whenever possible.
It’s easy to default to mutable collections out of habit. However, mutable collections can introduce unexpected changes and bugs. Always evaluate if an immutable collection can be used instead.
While immutability can lead to safer code, it can sometimes come with a performance cost, especially when working with large data structures that need frequent updates.
Kotlin’s Explicit Mutability, implemented through ‘val’ and ‘var’, is a fundamental feature that promotes safer, more predictable code. By making immutability the default and requiring explicit declaration for mutable variables, Kotlin encourages developers to think carefully about state management in their applications.
As with any language feature, the key to leveraging Explicit Mutability effectively lies in understanding its nuances and applying it judiciously. By following best practices and considering the principles of immutability, developers can write Kotlin code that is not only functional but also maintainable and robust.
Whether you’re building Android apps, server-side applications, or multiplatform projects, mastering Kotlin’s approach to mutability will serve you well in creating high-quality software. So next time you’re declaring a variable in Kotlin, take a moment to consider: should it be a ‘val’ or a ‘var’? Your future self (and your team) will thank you for it.
]]>This blog post will explore Kotlin’s null safety in detail, including its benefits, how it works, and practical examples to illustrate its application. Whether you are a seasoned developer or new to Kotlin, this comprehensive guide will help you understand and apply null safety guards effectively in your projects.
Null pointers are a common source of bugs and crashes in many programming languages. In Java, for instance, dereferencing a null reference results in a NullPointerException (NPE). These exceptions can be difficult to track down and fix, especially in large codebases.
For more history have a look at the talk “Null References: The Billion Dollar Mistake” by Tony Hoare, who describes the costly impact of null-related bugs.
Kotlin addresses the problem of null pointers by introducing a type system that differentiates between nullable and non-nullable types. This distinction allows Kotlin to enforce null checks at compile-time, significantly reducing the likelihood of NPEs.
Types are non-nullable by default. This means that a variable of type String cannot hold a null value:
1
2
var nonNullableString: String = "Hello, Kotlin"
// nonNullableString = null // Compile-time error
To declare a variable that can hold a null value, you append a ? to the type:
1
2
var nullableString: String? = null
nullableString = null // All good
By explicitly distinguishing between nullable and non-nullable types, Kotlin forces developers to think about nullability and handle it appropriately.
Kotlin provides a safe call operator ?. to handle nullable types safely. The safe call operator allows you to access properties and methods of a nullable
object without risking an NPE:
1
val length: Int? = nullableString?.length
In this example, nullableString?.length returns null if nullableString is null, otherwise it returns the length of the string. This prevents a potential NPE
and makes the code more concise and readable.
The Elvis operator ?: is another useful construct for dealing with nullable types. It allows you to provide a default value in case a nullable expression evaluates
to null:
1
val length: Int = nullableString?.length ?: 0
Here, if nullableString is null, the length will be set to 0. The Elvis operator is a concise way to handle null values and provide fallback logic.
Sometimes you might be certain that a nullable variable is not null at a particular point in your code. In such cases, you can use the not-null assertion operator !! to
tell the compiler that the value is not null:
1
val length: Int = nullableString!!.length
Use the not-null assertion operator with caution. If the variable is actually null, the application will throw an NPE at runtime, defeating the purpose of null safety! It is generally better to use safe calls and the Elvis operator to handle null values more gracefully.
Kotlin also provides null safety mechanisms for collections. You can declare collections of nullable or non-nullable types, and Kotlin’s type system ensures that you handle nullability correctly:
1
2
val nonNullableList: List<String> = listOf("Kotlin", "Java", "Swift")
val nullableList: List<String?> = listOf("Kotlin", null, "Swift")
When working with nullable collections, you can use functions like filterNotNull to remove null values:
1
println(nullableList.filterNotNull())
Which prints:
1
[Kotlin, Swift]
I encourage you to explore further Kotlin’s collections API as there are many more functions provided to make working with nulls easier.
Kotlin’s null safety extends to functions as well. You can define functions that accept nullable or non-nullable parameters and return nullable or non-nullable values. The type system enforces null safety at every step, preventing you from passing or returning null values where they are not expected.
Here’s an example of a function with a nullable parameter:
1
2
3
4
5
6
7
fun printLength(str: String?) {
if (str != null) {
println("Length: ${str.length}")
} else {
println("String is null")
}
}
The function printLength checks if the parameter str is null before attempting to access its length, ensuring that no NPE occurs.
Note that there’s no ? after checking that value is not null. Kotlin “knows” by utilising smart casts (on that later) that str
is not null and therefor treats it as such.
You can also define functions that return nullable types:
1
2
3
fun findString(strings: List<String>, query: String): String? {
return strings.find { it == query }
}
In this example, the function findString returns a nullable String.
Kotlin provides several related features to handle nullability more effectively, including smart casts, the let function, and the run function.
Kotlin’s smart cast feature automatically casts a nullable type to a non-nullable type after a null check (as we noticed in previous example in nullable parameters section):
1
2
3
4
5
6
7
fun printLength(str: String?) {
if (str != null) {
println("Length: ${str.length}") // str is automatically cast to non-nullable
} else {
println("String is null")
}
}
Smart casts reduce the need for explicit casting and make the code more concise and readable.
The let function belongs to scope functions and is a powerful tool for working with nullable values. It executes a block of code only if the value is not null:
1
nullableString?.let { println("Length: ${it.length}") }
The let function ensures that the block of code is only executed when nullableString is not null, providing a safe and idiomatic way to handle nullable values.
The run function is similar to let, but it allows you to work with a nullable object and return a result:
1
val lengthOrNull: Int? = nullableString?.run { length }
In this example, run executes the block of code if nullableString is not null and returns the result of the block. If nullableString is null, the result is null.
Kotlin’s null safety is a powerful feature that helps developers write safer and more reliable code by eliminating the risk of null pointer exceptions. By distinguishing between nullable and non-nullable types, providing safe call operators, and offering advanced features like smart casts and the let function, Kotlin ensures that nullability is handled explicitly and correctly.
Understanding and leveraging these features will make your Kotlin code more robust, maintainable, and less prone to runtime exceptions. Embrace Kotlin’s null safety and experience the benefits of a language designed to minimize common pitfalls and improve code quality.
]]>In this blog post, we’ll scrape the surface of what Kotlin power-assert is, how it works, and why you might consider incorporating it into your development workflow.
Kotlin power-assert is a compiler plugin that enhances assertion statements in your tests by providing detailed feedback when an assertion fails. Traditional assertions often leave developers with vague messages like “expected true but was false”, which can be frustrating and time-consuming to debug. Power-assert aims to solve this by offering more context and clarity.
To start using power-assert in your Kotlin project, you’ll need to enable the plugin. Check out the official Kotlin documentation on power-assert which gives up-to-date detailed guide on how to set it up and use it.
When an assertion fails, power-assert provides a detailed visual representation of the failed expression. This includes the values of variables and the structure of the expression at the time of failure. By doing so, it helps developers quickly pinpoint the cause of the failure without needing to manually insert print statements or debug through the code.
For example, consider the following traditional assertion:
1
assert(a * b == c + d)
If this assertion fails, a standard error message might tell you that the expression is false, but it won’t provide much context. With power-assert, the error message will break down the expression and show the values of a, b, c, and d, helping you pinpoint the cause of the failure more quickly.
And so you will see:
1
2
3
4
5
6
7
8
9
10
Assertion failed
assert(a * b == c + d)
| | | | | | |
| | | | | | 1
| | | | | 11
| | | | 10
| | | false
| | 1
| 12
12
This visualization clearly shows the values of a, b, c and d therefore making it immediately obvious why the assertion failed.
Consider the following data class and test
1
2
3
4
5
6
7
8
9
10
11
12
data class Person(
val firstName: String,
val lastName: String,
val age: Int
)
@Test
fun `power assert complex values`() {
val charlie = Person("Charlie", "Brown", 23)
val sally = Person("Sally", "Gray", 21)
assert(charlie.age == sally.age)
}
The plugin will show value for each of the objects and fields in the assertion, and will render the following:
1
2
3
4
5
6
7
8
Assertion failed
assert(charlie.age == sally.age)
| | | | |
| | | | 21
| | | Person(firstName=Sally, lastName=Gray, age=21)
| | false
| 23
Person(firstName=Charlie, lastName=Brown, age=23)
This output clearly shows how power-assert type of assertion can help with providing more context around tested expressions.
For a more comprehensive exploration of Kotlin’s power-assert have a look at the most recent talk from KotlinConf’24 by Brian Norman:
Also Duncan McGregor’s videos offer invaluable insights:
These videos delve into practical examples, highlight some problems and considerations when using power-assert.
Kotlin power-assert is an experimental yet promising feature that can significantly enhance the way we write and debug tests. By offering more informative and readable error messages, it helps developers quickly identify and fix issues. Although power-assert is not a new concept and has been implemented for several languages already (e.g. Java, Clojure, JS, Go), it’s great to see it making it’s way into Kotlin.
As Kotlin continues to evolve, tools like power-assert demonstrate the JetBrains commitment to providing developers with the best possible tools and features. Whether you’re a seasoned Kotlin developer or just getting started, incorporating power-assert into your testing strategy is worth considering.
]]>