← Back to all posts

Error Handling in TypeScript: Neverthrow, Try-Catch, and Alternatives like EffectTS

Error Handling in TypeScript: Neverthrow, Try-Catch, and Alternatives like EffectTS

Error handling is a critical aspect of writing robust and maintainable TypeScript applications. Traditional try-catch blocks, while functional, can lead to verbose and error-prone code, especially when dealing with asynchronous operations or third-party libraries. This article explores Neverthrow, a TypeScript library that offers a type-safe, functional approach to error handling, compares it to try-catch with additional problematic examples, and introduces EffectTS as a powerful alternative.

The Problem with Try-Catch

The try-catch statement is the standard mechanism for handling exceptions in JavaScript and TypeScript. It allows developers to execute code in a try block and catch any errors in a catch block. Here's a basic example:

async function fetchWeather(city: string): Promise<WeatherData> {
  try {
    const response = await axios.get(`https://api.weather.com/${city}`);
    return response.data;
  } catch (error) {
    throw new Error(`Failed to fetch weather: ${error.message}`);
  }
}

While effective for simple cases, try-catch has several drawbacks that become more apparent in complex scenarios:

  1. Lack of Type Safety: Errors in JavaScript/TypeScript are not type-safe. The catch block receives an unknown type, requiring manual type checking or casting, which can lead to runtime errors.
  2. Verbose and Nested Code: Asynchronous or multi-step operations often require multiple try-catch blocks, leading to deeply nested, repetitive code that is hard to maintain.
  3. Implicit Error Propagation: If a function throws an error and the caller forgets to wrap it in try-catch, the error can propagate unchecked, causing runtime crashes or unexpected behavior.
  4. No Enforcement: TypeScript does not enforce handling of errors, so developers may forget to account for error cases, especially with third-party libraries.

More Problematic Try-Catch Examples

To illustrate the issues with try-catch, here are additional examples showcasing common pitfalls:

Example 1: Nested Try-Catch for Multiple API Calls

Suppose you need to fetch user data, then their profile, and finally their posts, each depending on the previous step. A try-catch approach quickly becomes unwieldy:

async function fetchUserProfilePosts(userId: string): Promise<UserPosts> {
  try {
    const userResponse = await axios.get(`https://api.example.com/users/${userId}`);
    const user = userResponse.data;
    
    try {
      const profileResponse = await axios.get(`https://api.example.com/profiles/${user.profileId}`);
      const profile = profileResponse.data;
      
      try {
        const postsResponse = await axios.get(`https://api.example.com/posts?userId=${userId}`);
        return { user, profile, posts: postsResponse.data };
      } catch (error) {
        throw new Error(`Failed to fetch posts: ${error.message}`);
      }
    } catch (error) {
      throw new Error(`Failed to fetch profile: ${error.message}`);
    }
  } catch (error) {
    throw new Error(`Failed to fetch user: ${error.message}`);
  }
}

Issues:

  • Deep Nesting: The nested try-catch blocks make the code hard to read and maintain.
  • Error Handling Repetition: Each catch block repeats similar error-handling logic, increasing the chance of inconsistent error messages or missed cases.
  • No Type Safety: The error object is unknown, and accessing error.message assumes it exists, risking runtime errors if the error is malformed.

Example 2: Missing Error Handling

Developers often forget to wrap calls to functions that may throw errors, especially in larger codebases:

async function processUserData(userId: string): Promise<string> {
  const userData = await fetchUserProfilePosts(userId); // No try-catch!
  return `User ${userData.user.name} has ${userData.posts.length} posts`;
}

Issues:

  • Unchecked Errors: If fetchUserProfilePosts throws an error, processUserData will crash the application or propagate the error to higher levels, potentially causing unhandled promise rejections.
  • No Type Enforcement: TypeScript does not warn about the need to handle potential errors, leaving the code vulnerable.

Example 3: Inconsistent Error Types

When working with multiple third-party libraries, errors may have different shapes, leading to fragile error handling:

async function fetchDataFromMultipleSources(sourceId: string): Promise<Data> {
  try {
    const api1Response = await axios.get(`https://api1.com/data/${sourceId}`);
    const api2Response = await fetch(`https://api2.com/data/${sourceId}`).then(res => res.json());
    return { api1: api1Response.data, api2: api2Response };
  } catch (error) {
    if (error.response) {
      // Axios error
      throw new Error(`API error: ${error.response.status}`);
    } else if (error.message) {
      // Generic error
      throw new Error(`Fetch error: ${error.message}`);
    } else {
      // Unknown error
      throw new Error('Unknown error occurred');
    }
  }
}

Issues:

  • Complex Error Checking: The catch block must handle multiple error formats (e.g., Axios errors vs. native fetch errors), increasing complexity and the risk of missing cases.
  • Manual Type Casting: The developer must manually check properties like error.response, which TypeScript cannot verify, leading to potential runtime errors.
  • Maintenance Burden: Adding more APIs requires updating the error-handling logic, making it prone to errors.

These examples highlight how try-catch can lead to brittle, hard-to-maintain code, especially in complex or large-scale applications.

Enter Neverthrow: Type-Safe Error Handling

Neverthrow is a TypeScript library inspired by Rust's Result type, designed to eliminate the need for throw statements and provide explicit, type-safe error handling. It introduces two core types: Result<T, E> for synchronous operations and ResultAsync<T, E> for asynchronous ones. A Result is either Ok<T> (success with a value of type T) or Err<E> (failure with an error of type E).

How Neverthrow Works

Here’s how the weather-fetching example can be rewritten using Neverthrow:

import { Result, ok, err } from 'neverthrow';

interface WeatherData {
  temperature: number;
  condition: string;
}

interface WeatherError {
  message: string;
}

function fetchWeather(city: string): Result<WeatherData, WeatherError> {
  if (!isValidCity(city)) {
    return err({ message: 'Invalid city name' });
  }

  try {
    const response = axios.get<WeatherData>(`https://api.weather.com/${city}`);
    return ok(response.data);
  } catch (error) {
    return err({ message: `Failed to fetch weather: ${error.message}` });
  }
}

// Usage
const result = fetchWeather('London');
if (result.isOk()) {
  console.log(`Temperature: ${result.value.temperature}`);
} else {
  console.error(result.error.message);
}

For asynchronous operations, ResultAsync simplifies the process:

import { ResultAsync, ok, err } from 'neverthrow';

async function fetchWeatherAsync(city: string): ResultAsync<WeatherData, WeatherError> {
  if}}$ if (!isValidCity(city)) {
    return err({ message: 'Invalid city name' });
  }

  return ResultAsync.fromPromise(
    axios.get<WeatherData>(`https://api.weather.com/${city}`),
    (error) => ({ message: `Failed to fetch weather: ${error.message}` })
  ).map((response) => response.data);
}

// Usage
fetchWeatherAsync('London').then((result) =>
  result.match(
    (data) => console.log(`Temperature: ${data.temperature}`),
    (error) => console.error(error.message)
  )
);

Rewriting the Problematic Try-Catch Example with Neverthrow

Let’s rewrite the nested fetchUserProfilePosts example using Neverthrow to demonstrate its advantages:

import { ResultAsync } from 'neverthrow';

interface User {
  id: string;
  name: string;
  profileId: string;
}

interface Profile {
  bio: string;
  avatar: string;
}

interface Post {
  id: string;
  content: string;
}

interface UserPosts {
  user: User;
  profile: Profile;
  posts: Post[];
}

interface AppError {
  message: string;
}

async function fetchUser(userId: string): ResultAsync<User, AppError> {
  return ResultAsync.fromPromise(
    axios.get<User>(`https://api.example.com/users/${userId}`),
    (error) => ({ message: `Failed to fetch user: ${error.message}` })
  ).map((response) => response.data);
}

async function fetchProfile(profileId: string): ResultAsync<Profile, AppError> {
  return ResultAsync.fromPromise(
    axios.get<Profile>(`https://api.example.com/profiles/${profileId}`),
    (error) => ({ message: `Failed to fetch profile: ${error.message}` })
  ).map((response) => response.data);
}

async function fetchPosts(userId: string): ResultAsync<Post[], AppError> {
  return ResultAsync.fromPromise(
    axios.get<Post[]>(`https://api.example.com/posts?userId=${userId}`),
    (error) => ({ message: `Failed to fetch posts: ${error.message}` })
  ).map((response) => response.data);
}

async function fetchUserProfilePosts(userId: string): ResultAsync<UserPosts, AppError> {
  return fetchUser(userId).andThen((user) =>
    fetchProfile(user.profileId).andThen((profile) =>
      fetchPosts(userId).map((posts) => ({ user, profile, posts }))
    )
  );
}

// Usage
fetchUserProfilePosts('123').then((result) =>
  result.match(
    (data) => console.log(`User ${data.user.name} has ${data.posts.length} posts`),
    (error) => console.error(error.message)
  )
);

Improvements:

  • No Nesting: The andThen method chains operations, keeping the code flat and readable.
  • Type Safety: AppError is explicitly typed, ensuring consistent error handling.
  • Explicit Handling: The ResultAsync type forces the caller to handle both success and error cases via match.
  • Reusability: Each function (fetchUser, fetchProfile, fetchPosts) is modular and reusable.

Benefits of Neverthrow

  1. Type Safety: Both the success value (T) and error (E) are explicitly typed, allowing TypeScript to enforce proper handling and prevent runtime errors.
  2. Explicit Error Handling: The Result type forces developers to handle both Ok and Err cases, reducing the risk of unhandled errors.
  3. Functional Programming: Neverthrow supports methods like map, andThen, and match, enabling a railway-oriented programming style where operations are chained elegantly.
  4. No Unchecked Throws: By wrapping third-party code in Result or ResultAsync, Neverthrow ensures that errors are captured and handled explicitly.
  5. Improved Readability: Compared to nested try-catch blocks, Neverthrow produces cleaner, more maintainable code.

Drawbacks of Neverthrow

  1. Learning Curve: Developers unfamiliar with functional programming or Rust’s Result type may find Neverthrow’s API initially challenging.
  2. Verbosity: In simple cases, wrapping results in Result can feel more verbose than try-catch.
  3. Integration with Existing Code: Retrofitting Neverthrow into a codebase heavy with try-catch requires significant refactoring.

Try-Catch vs. Neverthrow: A Comparison

| Feature | Try-Catch | Neverthrow | | ------------------------ | ----------------------------------- | --------------------------------------- | | Type Safety | Not type-safe; errors are unknown | Fully type-safe with Result<T, E> | | Error Handling | Implicit; requires manual checks | Explicit; forces handling of Ok/Err | | Asynchronous Support | Requires try-catch for async | Seamless with ResultAsync | | Code Readability | Can become nested and verbose | Cleaner with functional methods | | Enforcement | No compiler enforcement | Compiler enforces error handling | | Use Case | Simple scripts, quick prototyping | Large-scale, type-safe applications |

For small projects or prototyping, try-catch may suffice due to its simplicity. However, for applications requiring robust error handling and type safety, Neverthrow is a superior choice, as demonstrated by its ability to simplify complex scenarios like the fetchUserProfilePosts example.

Alternative: EffectTS

While Neverthrow is excellent for type-safe error handling, EffectTS is a more comprehensive library that goes beyond error handling to address concurrency, dependency injection, logging, and more. It provides a functional programming paradigm inspired by languages like Haskell and Scala, using an Effect type to manage computations that may fail or depend on external resources.

How EffectTS Works

EffectTS represents computations as Effect<R, E, A>, where:

  • R is the environment or dependencies required.
  • E is the error type.
  • A is the success value.

Here’s an example of fetching weather data with EffectTS:

import * as Effect from '@effect/io/Effect';
import * as Context from '@effect/data/Context';
import { pipe } from '@effect/data/Function';

// Define a service for HTTP requests
interface HttpService {
  get: (url: string) => Promise<WeatherData>;
}

const HttpService = Context.Tag<HttpService>();

// Weather fetching effect
const fetchWeather = (city: string) =>
  Effect.gen(function* (_) {
    if (!isValidCity(city)) {
      return yield* Effect.fail({ message: 'Invalid city name' });
    }
    const http = yield* _(HttpService);
    const data = yield* Effect.tryPromise({
      try: () => http.get(`https://api.weather.com/${city}`),
      catch: (error) => ({ message: `Failed to fetch: ${error.message}` }),
    });
    return data;
  });

// Provide the service and run
const program = pipe(
  fetchWeather('London'),
  Effect.provideService(HttpService, {
    get: (url) => axios.get(url).then((res) => res.data),
  })
);

Effect.runPromise(program)
  .then((data) => console.log(`Temperature: ${data.temperature}`))
  .catch((error) => console.error(error.message));

Benefits of EffectTS

  1. Comprehensive Solution: Beyond error handling, EffectTS manages async operations, retries, timeouts, and dependency injection, reducing the need for additional libraries.
  2. Type Safety: Like Neverthrow, it enforces type-safe error handling but extends this to dependencies and resources.
  3. Functional Paradigm: It supports advanced functional programming patterns, making it ideal for complex applications.
  4. Scalability: Its ability to handle concurrency and dependencies makes it suitable for large-scale systems.

Drawbacks of EffectTS

  1. Complexity: EffectTS has a steep learning curve, especially for developers not versed in functional programming.
  2. Verbosity: Simple tasks can require more code compared to Neverthrow or try-catch.
  3. Overkill for Simple Projects: Its extensive feature set may be unnecessary for smaller applications where Neverthrow or try-catch suffices.

Neverthrow vs. EffectTS

| Feature | Neverthrow | EffectTS | | ------------------ | --------------------------------- | ------------------------------------- | | Scope | Focused on error handling | Handles errors, concurrency, DI, etc. | | Learning Curve | Moderate | Steep | | Verbosity | Moderate | High | | Type Safety | Excellent | Excellent | | Use Case | Error handling in TypeScript apps | Complex, scalable systems |

If your primary concern is error handling, Neverthrow is simpler and more focused. For applications requiring advanced concurrency or dependency management, EffectTS is a better fit.

Other Alternatives

Beyond Neverthrow and EffectTS, other libraries offer similar functionality:

  • fp-ts: A functional programming library with Either and TaskEither types for error handling, similar to Neverthrow but more general-purpose.
  • ts-results: A lightweight Result type implementation, less feature-rich than Neverthrow but simpler.
  • oxide.ts: Another Rust-inspired library for type-safe error handling, with a focus on simplicity.

Conclusion

Error handling in TypeScript requires careful consideration to ensure type safety and maintainability. The try-catch approach, while simple, often leads to nested, verbose, and error-prone code, as shown in the problematic examples above. Neverthrow offers a robust, type-safe alternative inspired by Rust’s Result type, making it ideal for applications where error handling is a priority, especially in complex scenarios like chained API calls. For more advanced needs, EffectTS provides a comprehensive functional programming framework, though it comes with increased complexity.

Choose Neverthrow for straightforward, type-safe error handling, EffectTS for scalable systems with advanced requirements, or stick with try-catch for quick prototypes. By understanding the strengths and trade-offs of each approach, you can make an informed decision for your next TypeScript project.

Resources:

  • Neverthrow Documentation

  • EffectTS Documentation

  • Rust’s Guide on Error Handling