TypeScript Error Handling Patterns That Actually Work

Why try/catch is Not Enough

The traditional JavaScript pattern for error handling is try/catch. The problem? TypeScript has no way to type what errors are thrown. The caught error is always typed as unknown, meaning you lose type safety the moment something goes wrong.

Pattern 1: The Result Type

The Result pattern represents the outcome of an operation that can either succeed or fail. It eliminates the need for try/catch in most cases:

export type ApiErrorCode =
  | 'NOT_FOUND'
  | 'UNAUTHORIZED'
  | 'FORBIDDEN'
  | 'INTERNAL_ERROR';

export type ActionResult<T> =
  | { success: true; data: T }
  | { success: false; error: {
      code: ApiErrorCode;
      message: string;
    }};

// Usage — TypeScript enforces you handle both branches:
const result = await fetchUser(id);

if (!result.success) {
  // result.error.code is strongly typed → 'NOT_FOUND' | 'UNAUTHORIZED' | ...
  switch (result.error.code) {
    case 'NOT_FOUND': return show404();
    case 'UNAUTHORIZED': return redirectToLogin();
    default: return showGenericError();
  }
}

// result.data is guaranteed to exist here
renderUser(result.data);

Pattern 2: The Either Type (Functional Style)

Inspired by functional programming languages like Haskell and Scala, Either represents a value that is one of two possible types — conventionally Left (failure) and Right (success):

export type Either<E, T> =
  | { _tag: 'Left'; error: E }
  | { _tag: 'Right'; value: T };

// Type guard helper (auto-generated by the tool)
export const isLeft = <E, T>(e: Either<E, T>): e is { _tag: 'Left'; error: E } =>
  e._tag === 'Left';

// Usage:
const result: Either<ApiError, User> = await getUser(id);

if (isLeft(result)) {
  console.error(result.error); // typed as ApiError
} else {
  console.log(result.value);  // typed as User
}

Pattern 3: Validation Error Types

Form validation errors need a different structure — a field-keyed map of error messages that your UI components can consume directly:

export type ValidationErrorCode = 'VALIDATION_FAILED' | 'INVALID_INPUT';

export interface ValidationError {
  code: ValidationErrorCode;
  message: string;
  errors: Record<string, string[]>; // { "email": ["Invalid format", "Required"] }
}

// React usage:
if (!result.success && result.error.code === 'VALIDATION_FAILED') {
  const { errors } = result.error;
  setFieldError('email', errors.email?.[0]);
  setFieldError('password', errors.password?.[0]);
}

When to Use Which Pattern

• Result Type — Best for async operations (API calls, file reads). Simple, intuitive, works with React Query's error states.
• Either Type — Best for functional pipelines and composing multiple fallible operations without nested if-statements.
• Validation Error — Best for form submission responses where field-level granularity is required.
• Auth Error Type — Best for authentication middleware that needs expiry timestamps and realm information.

Frequently Asked Questions