Either: What It Is, How It Works, and Practical Use

What Is Either?

Either is an algebraic data type, borrowed from functional programming, that represents exactly one of two possible types. In the context of error handling, the convention is: the Left type (Left) contains a problem description, while the Right type (Right) holds a successful result.

The concept of Either originates from the Haskell language and the type category Either a b, where a is the type of the left value and b is the type of the right. In mobile development, Either gained popularity thanks to the Arrow library for Kotlin and functional approaches in Swift.

The key advantage of Either over exceptions is no hidden execution paths. A function returning Either explicitly declares in its signature that it may fail. The compiler ensures both variants are handled.

Unlike throwing exceptions, Either preserves data flow transparency. Calling a function that returns Either does not require try-catch on the caller side — pattern matching or fold is sufficient. This is especially important in architectures with a reactive approach, where each data source returns Either and transformation chains are built using map and flatMap.

How Either Works: Left and Right Structure

Either consists of two subtypes: Left and Right. An Either instance can only be one of them at any given time. The typical signature in Kotlin looks like Either<E, A>, where E is the error type and A is the success value type.

Left Type: Error Container

Left represents the failure case. Unlike exceptions, Left does not interrupt the execution flow — it simply returns a value that needs to be handled. The error type can be anything: String, Int, a custom sealed class, or a domain model.

Right Type: Success Container

Right holds the correct operation result. The name reflects correctness — by convention, Right means success. Transformations like map and flatMap are applied to Right, enabling computation chains without checking each step.

Composing Either with flatMap

flatMap is the primary mechanism for composing Either. If the current value is Right, flatMap applies the passed function and returns a new Either. If it is Left, flatMap skips the transformation and propagates the error. This behavior is called short-circuit evaluation.

Besides flatMap, Either supports mapLeft for error transformation, fold for handling both variants in one place, and getOrElse for extracting a value with a default. These functions cover all scenarios: from simple extraction to complex composition with asynchronous calls in Kotlin coroutines or Swift Combine.

fun parseInt(input: String): Either<String, Int> =
    input.toIntOrNull()?.let { Right(it) }
    ?: Left("Failed to convert: $input")

fun divide(a: Int, b: Int): Either<String, Int> =
    if (b == 0) Left("Division by zero")
    else Right(a / b)

val result = parseInt("10")
    .flatMap { divide(it, 2) }

Either in Kotlin: Practical Application

In the Kotlin ecosystem, Either is implemented in the Arrow library. The Kotlin standard library offers Result, but Either provides more flexibility: arbitrary error types, composition via flatMap, and support for functional patterns.

Arrow Library and Either

Arrow is a functional library for Kotlin that adds Either, Option, Validated, and other types. Arrow.Either is a sealed class with two subclasses: ArrowCore.Left and ArrowCore.Right. The library also provides convenient extensions: .getOrElse(), .fold(), .mapLeft().

Example: Either with a Network Request

Consider a real-world scenario — a network request in an Android app with possible errors: no network, server error, invalid response. Either allows combining all variants into a single return type.

sealed class NetworkError {
    data class NoConnection(val message: String): NetworkError()
    data class ServerError(val code: Int): NetworkError()
    data class ParseError(val detail: String): NetworkError()
}

suspend fun fetchUser(id: String): Either<NetworkError, User> {
    return try {
        val response = api.getUser(id)
        if (response.isSuccessful) {
            Right(response.body()!!)
        } else {
            Left(NetworkError.ServerError(response.code()))
        }
    } catch (e: IOException) {
        Left(NetworkError.NoConnection(e.message ?: ""))
    }
}

Either in Swift: Difference from Standard Result

In Swift, starting from version 5.0, the built-in Result type is available, which is conceptually similar to Either but has limitations: the error must conform to the Error protocol, and the success value must be a single type. Either in Swift is implemented using an enum with two generic parameters.

Standard Result vs. Either

Result<Success, Failure> is Swift's built-in type, where Failure: Error. Either does not impose constraints on the error type, allowing it to store String, custom structures, or even multiple error types through nested enums.

enum Either<E, A> {
    case left(E)
    case right(A)

    func map<B>(_ transform: (A) -> B) -> Either<E, B> {
        switch self {
        case .left(let e): return .left(e)
        case .right(let a): return .right(transform(a))
        }
    }
}

let result: Either<String, Int> = .right(42)
let mapped = result.map { $0 * 2 }

When to Use Either in Mobile Apps

Either is optimal for scenarios requiring explicit and type-safe error handling without exceptions. Consider the main use cases in mobile development with Kotlin and Swift.

• Network requests — each request may return a connection error, server error, or parsing error. Either collects all variants into one type.
• Form validation — Either with a custom error type conveniently represents input field validation results: invalid email or password.
• Data repository — Either allows combining results from different sources (cache, database, network) with a unified error type.
• Command interpreter — if an app parses user input or commands, Either provides a type-safe way to report errors.

Avoid using Either for simple operations without side effects — a regular return value is more reliable and easier to read. Either is also excessive when failure is an exceptional situation rather than an expected scenario.

Either is also efficient when working with coroutines in Kotlin. A function returning Either can be called inside a coroutine with error handling via fold or mapLeft without blocking the thread. This is especially useful in Android apps with MVVM architecture, where each repository returns Either and the ViewModel transforms the result into UiState.

Common Mistakes When Working with Either

Developers new to Either often make similar mistakes. Let us examine the most common ones and how to avoid them.

• Ignoring Left — calling .getOrElse() with a default value without analyzing the error reason defeats the purpose of using Either. Always handle the error explicitly.
• Global error type — using String or Exception as a common type for all Either instances in a project reduces type safety. Create domain sealed classes.
• Nested Either — a nested Either inside Right (Either<E, Either<E, A>>) complicates readability. Use flatMap for flattening.
• Mixing with exceptions — a function returns Either but throws exceptions internally. This contradicts the idea of explicit error handling.