JavaScript Either Monad Error Handling

What is the Either Monad?

The Either monad is a powerful functional programming pattern for handling errors in JavaScript. Unlike traditional try-catch blocks that interrupt program flow, Either provides a way to represent and compose operations that might fail.

Think of Either as a container that holds one of two possible values: a Left value representing failure or error, or a Right value representing success. This elegant design allows you to build robust error-handling pipelines without the complexity of exception-based control flow.

The core problem Either solves is making errors explicit in your function signatures rather than hiding them in thrown exceptions. When a function returns Either, callers know immediately that the operation might fail--they cannot ignore the error case without explicitly handling it. This aligns perfectly with modern functional programming practices in JavaScript, where values flow through transformations rather than control structures determining execution paths. By representing both success and failure as ordinary values, Either enables you to compose operations declaratively, transforming data through pipelines while errors propagate naturally.

This approach has roots in languages like Haskell and Scala, where Either is a standard tool for error handling. JavaScript developers are increasingly adopting these patterns as applications grow more complex and the limitations of exception-based error handling become apparent at scale. For teams working with TypeScript enum patterns, Either provides a complementary approach to handling expected failure conditions alongside compile-time type safety.

Try-Catch vs Either: Understanding the Trade-offs

Traditional exception handling with try-catch has served JavaScript developers well, but it comes with significant drawbacks in complex applications.

The Problem with Exceptions

Exceptions break the synchronous flow of your code, making it difficult to compose operations. When a function throws an exception, it can unexpectedly terminate entire call stacks, and it's all too easy to accidentally silence errors by forgetting catch blocks. The error context often gets lost in the process, especially when errors bubble up through multiple layers of function calls. This creates what functional programmers call "action at a distance"--a small error in one function can cause a cascade of failures far removed from its source.

Try-catch also makes it challenging to compose multiple operations that might fail. You end up nesting try-catch blocks deeply or wrapping each individual operation, leading to code that is difficult to read and maintain. The error handling becomes tangled with the business logic, obscuring the actual intent of your code.

Either addresses each of these problems directly. Control flow disruption is eliminated because errors become ordinary values that flow through your pipeline. Silent failures become impossible because you must explicitly handle both Left and Right cases. Composability improves dramatically because functions that return Either can be chained together with map and chain operations, with errors automatically propagating through the chain without explicit handling at each step.

As explained by LogRocket's analysis of error handling patterns, this shift from exception-based to value-based error handling represents a fundamental change in how you think about failure in your applications. Combined with TypeScript abstract class patterns, Either monads enable a more declarative approach to building robust JavaScript applications.

The Left and Right Paths

The Either monad derives its name from the simple concept of having two mutually exclusive paths: either a Left value or a Right value.

By convention in functional programming, Right represents the happy path--the successful result of a computation. Left represents the alternative path, typically used for errors or failures. This naming might seem arbitrary at first, but it becomes intuitive once you start thinking in terms of railway tracks, where the right track continues forward while the left track might lead to an error station.

The beauty of this approach is that errors become ordinary values that flow through your program just like successful results, rather than exceptional events that disrupt control flow. Consider this simple example:

const user = Right({ name: 'Alice', email: '[email protected]' });
const error = Left(new Error('Validation failed'));

Both user and error are Either instances. You can pass them through the same functions, chain transformations on both, and extract the value or handle the error at the end. The key insight is that errors are not exceptional--they are expected outcomes that your code handles explicitly.

James Sinclair's foundational Either tutorial emphasizes that Left and Right form a complete algebra: any operation you can perform on a Right can be composed with other Rights, while Left values propagate unchanged through your transformations. This aligns well with modern TypeScript decorator patterns for creating reusable, composable abstractions.

Implementing the Either Monad

Building a basic Either implementation in JavaScript is straightforward. The key is creating two classes--Left and Right--that share a common interface but behave differently based on which type they are.

Basic Class Structure

// Left represents the error/failure path
class Left {
 constructor(value) {
 this._value = value;
 }

 isLeft() {
 return true;
 }

 isRight() {
 return false;
 }
}

// Right represents the success/happy path
class Right {
 constructor(value) {
 this._value = value;
 }

 isLeft() {
 return false;
 }

 isRight() {
 return true;
 }
}

Both classes store their value internally and provide isLeft() and isRight() methods for type checking. The actual value is accessible through a getter, though typically you extract values through pattern matching or helper methods rather than direct access.

To create instances, you simply call the constructors:

const success = Right(42);
const failure = Left(new Error('Something went wrong'));

The elegance of this simple structure is that both success and failure are now values that can be passed through the same pipeline, transformed by the same methods, and handled by the same patterns.

Essential Methods: Map and Chain

The power of Either lies in its methods for transforming and composing values.

The Map Method

The map method transforms the value inside a Right instance while leaving Left instances unchanged. This enables function composition on the happy path, where successful values can be transformed through a pipeline of operations. When an error occurs (Left), the transformations are skipped, and the error continues to propagate:

Right.prototype.map = function(fn) {
 return this.isLeft() ? this : Right(fn(this._value));
};

// Usage:
const result = Right(5)
 .map(x => x * 2) // Right(10)
 .map(x => x + 1); // Right(11)

const errorResult = Left('error')
 .map(x => x * 2) // Left('error') - unchanged
 .map(x => x + 1); // Left('error') - unchanged

The Chain Method

Chain (also known as flatMap or bind) is essential for composing operations that themselves return Either instances. Unlike map, which wraps the result in another Either, chain flattens the nested structure:

Right.prototype.chain = function(fn) {
 return this.isLeft() ? this : fn(this._value);
};

// Usage with functions returning Either:
const parseNumber = str => {
 const n = parseInt(str, 10);
 return isNaN(n) ? Left(new Error('Not a number')) : Right(n);
};

const double = n => Right(n * 2);

const result = Right('5')
 .chain(parseNumber) // Right(5)
 .chain(double); // Right(10)

const failed = Right('abc')
 .chain(parseNumber) // Left(Error('Not a number'))
 .chain(double); // Left(Error('Not a number')) - short-circuited

OpenReplay's monad patterns guide demonstrates how chain enables powerful composition patterns where each operation can fail independently and errors short-circuit the entire pipeline.

Real-World Error Handling Patterns

Converting your existing code to use Either requires thoughtful consideration of your error handling strategy.

Wrapping Functions with Either

The first step is creating functions that return Either instead of throwing exceptions. This involves catching any exceptions and wrapping them in a Left instance, while successful results become Right instances:

const tryCatch = fn => {
 try {
 return Right(fn());
 } catch (e) {
 return Left(e);
 }
};

// Wrapping a risky function:
const parseJson = json => {
 try {
 return Right(JSON.parse(json));
 } catch (e) {
 return Left(e);
 }
};

Building Error-Handling Pipelines

Once your functions return Either, you can chain them together using map and chain. Each step in the pipeline receives the successful value from the previous step, and any error short-circuits the entire pipeline:

const validateUser = user => {
 return user.name ? Right(user) : Left(new Error('Name required'));
};

const sanitizeEmail = user => {
 const email = user.email.toLowerCase().trim();
 return email.includes('@') 
 ? Right({ ...user, email })
 : Left(new Error('Invalid email'));
};

const processUser = user => {
 return Right(user)
 .chain(validateUser)
 .chain(sanitizeEmail)
 .map(u => ({ ...u, processed: true }));
};

Pattern Matching and Error Recovery

At the end of your pipeline, you'll need to extract the value or handle the error. The getOrElse method provides a clean way to handle this:

Right.prototype.getOrElse = function(defaultValue) {
 return this.isLeft() ? defaultValue : this._value;
};

// Usage:
const user = processUser({ name: 'Alice', email: '[email protected]' })
 .getOrElse({ name: 'Guest', email: '' });

// For more complex handling, use fold:
const handleResult = either => {
 return either.fold(
 error => ({ status: 'error', message: error.message }),
 value => ({ status: 'success', data: value })
 );
};

Start by wrapping functions at your application boundaries--places where errors enter your system. Gradually extend Either patterns inward as you refactor existing code.

Conclusion

The Either monad offers a compelling alternative to traditional exception-based error handling in JavaScript. By making errors explicit values rather than exceptional events, Either enables more composable, maintainable code that clearly communicates its failure modes.

The pattern's strength lies in its simplicity: representing two possible outcomes as a container type allows errors to flow through your program just like successful values. Functions can be chained together with map and chain, with errors automatically propagating without explicit handling at each step. This leads to code that is not only cleaner but more reliable--you cannot accidentally ignore an error when every Either value must be handled.

As James Sinclair's foundational tutorial demonstrates, the Either monad transforms error handling from a concern scattered throughout your codebase into a centralized, composable pattern. LogRocket's analysis shows how this approach scales elegantly as applications grow more complex.

While adopting Either requires a shift in thinking from exception-based patterns, the benefits for complex applications are substantial. Start by experimenting with Either in isolated parts of your codebase, such as data transformation pipelines or API integration layers. As you become comfortable with the pattern, you'll find natural opportunities to apply it more broadly across your application.

For teams building modern JavaScript applications with Next.js, Either provides a robust foundation for handling errors declaratively, keeping your code focused on business logic rather than error management complexity. Combined with TypeScript enum patterns and other modern TypeScript features, Either monads help create type-safe, maintainable codebases that gracefully handle expected failure conditions.

Sources

1. James Sinclair - Elegant Error Handling with the JavaScript Either Monad
2. LogRocket - Using the JavaScript Either Monad for Error Handling
3. OpenReplay - Better Error Handling with Monads Part 2