Theo's preferred way of handling try/catch in TypeScript

try-catch.ts

// Types for the result object with discriminated union
type Success<T> = {
  data: T;
  error: null;
};

type Failure<E> = {
  data: null;
  error: E;
};

type Result<T, E = Error> = Success<T> | Failure<E>;

// Main wrapper function
export async function tryCatch<T, E = Error>(
  promise: Promise<T>,
): Promise<Result<T, E>> {
  try {
    const data = await promise;
    return { data, error: null };
  } catch (error) {
    return { data: null, error: error as E };
  }
}

This uses a [data, error] tuple, similar to Go or React’s useState, simplifying variable naming and reducing boilerplate. It handles both sync and async cases, making error handling more structured and readable.

The repo includes unit tests and CI. It’s also a single-file utility, so you can either copy-paste it into your project (MIT licence) or use it as a package:

npm install @maxmorozoff/try-catch-tuple

Repo: maxmorozoff/try-catch-tuple

Example

// Using tryCatch
const getData = async () => {
  let [data, err] = await tryCatch(badFunc);
  if (!err) return Response.json({ data });

  [data, err] = await tryCatch(badFunc);
  if (!err) return Response.json({ data });

  [data, err] = await tryCatch(goodFunc);
  if (!err) return Response.json({ data });

  return Response.error();
};

// Using tryCatch with constants
const getDataConst = async () => {
  const [data1, err1] = await tryCatch(badFunc);
  if (!err1) return Response.json({ data: data1 });

  const [data2, err2] = await tryCatch(badFunc);
  if (!err2) return Response.json({ data: data2 });

  const [data3, err3] = await tryCatch(goodFunc);
  if (!err3) return Response.json({ data: data3 });

  return Response.error();
};

// Using try...catch
const getDataStandard = async () => {
  try {
    const data = await badFunc();
    return Response.json({ data });
  } catch (err) {
    try {
      const data = await badFunc();
      return Response.json({ data });
    } catch (err) {
      try {
        const data = await goodFunc();
        return Response.json({ data });
      } catch (err) {
        return Response.error();
      }
    }
  }
};

async function goodFunc() {
  if (false) throw "no data";
  return "some data";
}

async function badFunc() {
  throw "no data";
  return "";
}

Try it in TypeScript Playground: TS Playground Link

returned as an array?

It’s actually much cleaner to use tuples instead of objects—no need to rename keys while destructuring.

Check out safe-wrapper on github or npm, it takes a slightly different approach by returning a [error, result] tuple that works with both synchronous and asynchronous functions.

You can implement the wrapper by simply wrapping your existing functions directly or creating safe versions of them. Additionally, it lets you specify which error types to handle and even supports custom handlers or transformers for more tailored error responses.

import { safe } from 'safe-wrapper';

// ? custom error for specific error handling
class CustomError extends Error {
  constructor(message) {
    super(message);
    this.name = 'CustomError';
  }
}

// ? optional transformer function to format error
const transformer = (error) => ({
  code: error.name,
  message: error.message,
  timestamp: new Date().toISOString()
});

/**
 * safe() accepts three parameters:
 * - a function to wrap (required).
 * - an array of arguments to pass to the function (optional).
 *   - only errors matching these types will be caught and returned. anything else will be thrown.
 *   - if no arguments are provided, all errors will be caught.
 * - a callback function (transformer) to run if an error is caught (optional).
 *   - if provided, the transformer will be called with the error as its only argument.
 *   - if not provided, the error will be returned as-is.
*/

const safeAction = safe((input) => { // ? for async simply safe(async (input) => { ... });
  if (typeof input === 'undefined') {
    throw new CustomError('input cannot be undefined');
  }

  if (typeof input !== 'string') {
    throw new TypeError('input must be a string');
  }

  if (input === '') {
    // ? this error will throw as it is not in the array of errors to catch
    throw new NonExistentError('input cannot be empty');
  }
  
  return input.toUpperCase();
}, [TypeError, CustomError], transformer);

const usage = () => {
  const [error, result] = safeAction('hello world');
  if (error) {
    return handler(error);
  }

  return result;
};

This project started out as something I really needed, and since I'm primarily a JS dev, it was originally written in JavaScript. Then a friend needed a similar solution for his TypeScript codebase, so I added types via JSDoc—which made it mostly usable except for some real edge-case scenarios.

Now I'm in the process of migrating the entire thing to TypeScript. I'm still learning, so any help—be it PRs, code reviews, or suggestions—would be hugely appreciated!

📦 A super simple lib to wrap both async and sync throwable functions into result type - https://github.com/tanishqmanuja/lib.result
🌟 BONUS: the source code is in a single file making it easy to drop this into existing codebase if you want to avoid extra deps.

By the way, would it be a good idea to return a tuple instead of an object?

type Result<T, E = Error> = [T, null] | [null, E];

export async function tryCatch<T, E = Error>(
  promise: Promise<T>,
): Promise<Result<T, E>> {
  try {
    const data = await promise;
    return [data, null];
  } catch (error) {
    return [null, error as E];
  }
}

The advantage is that we don't have to rename for multiple tryCatch like:
const { data: authData, error: authError } = await tryCatch()
const { data: apiData, error: apiError } = await tryCatch()

and can just do:
const [authData, authError] = await tryCatch()
const [apiData, apiError] = await tryCatch()
similar to how setState is used in react. Any downsides to doing it this way?

Edit: Seems like I missed the earlier posts, there's already a few libraries that does this.

The return type is unnecessary. It doesn't change the inferred type

export async function tryCatch<T, E = Error>(promise: Promise<T>) {
  try {
    const data = await promise;
    return { data, error: null };
  } catch (error) {
    return { data: null, error: error as E };
  }
}

And returning a tuple would make it nicer to use. And I'd also allow sync values, since it's easy

export async function tryCatch<T, E = Error>(promise: T | Promise<T>) {
  try {
    const data = await promise;
    return [null, data] as const;
  } catch (error) {
    return [error as E, null] as const;
  }
}

And returning a tuple would make it nicer to use. And I'd also allow sync values, since it's easy

export async function tryCatch<T, E = Error>(promise: T | Promise<T>) {
  try {
    const data = await promise;
    return [null, data] as const;
  } catch (error) {
    return [error as E, null] as const;
  }
}

Data and error positions should be swapped imo. Like so:

export async function tryCatch<T, E = Error>(promise: T | Promise<T>) {
  try {
    const data = await promise;
    return [data, null] as const;
  } catch (error) {
    return [null, error as E] as const;
  }
}

Data and error positions should be swapped imo.

Either one is fine.
Error first makes discarding data look nicer const [err] = tryCatch(...) vs const [, err] = tryCatch(...)
Value first makes it easier to swallow errors.
IMO, swallowing errors should look uglier)

For context, there is a discussion about error and data positioning here:
arthurfiorette/proposal-try-operator#13

Hello @t3dotgg , There’s already a solution for this provided by DefinitelyTyped. Your approach seems a bit overcomplicated and could be simplified. The DefinitelyTyped solution is just one line of code, making it more concise.

Link: @types/try-catch

result: any ... pass ...

Why not just using .catch() instead?

const result = await thing().catch((error: unknown) => {
  if (error instanceof ThingNotFoundError) {
    return null;
  }

  throw error;
});

Because tryCatch is about handling errors within your function calls, not just catching them. With tryCatch, I can change the results of the function I'm writing, based on the results of the error, like if I throw a USER_NOT_FOUND error, i could potential create the user and rerun the result without nested syntax.

I made a version that can be destructured by arrays and objects: https://github.com/osoclos/czy-js

it handles async and non-async functions quite well as well.

/**

* Represents a successful operation result.

* @template T - The type of the successful result data.
  */
  type Success = {
  data: T;
  error?: never;
  };

/**

* Represents a failed operation result.

* @template E - The type of the error object.
  */
  type Failure = {
  data?: never;
  error: E;
  };

/**

* Represents the result of an operation which can either be a success or a failure.

* @template T - The type of the successful result data.

* @template E - The type of the error object (default is `Error`).
  */
  type Result<T, E = Error> = Success | Failure;

/**

* Represents a value that may be a promise or a direct value.

* @template T - The type of the value.
  */
  type MaybePromise = T | Promise;

/**

* Executes a synchronous or asynchronous operation and handles any errors that occur.

* This function allows you to handle both synchronous and asynchronous operations

* using a unified approach. It returns a `Result` object containing either the

* successful data or an error object.

* @template T - The type of the successful result data.

* @template E - The type of the error object (default is `Error`).

* @param {Promise | (() => MaybePromise)} arg -

* ```
     A function that returns a value or a promise, or a direct promise.
  ```

* @returns {Result<T, E> | Promise<Result<T, E>>} -

* ```
       Returns a `Result` object containing the result data or an error.
  ```

* @example

* // Example usage with a synchronous function:

* const result = tryCatch(() => JSON.parse('{"key": "value"}'));

* if (result.data) {

* console.log(result.data); // Output: { key: 'value' }

* } else {

* console.error(result.error.message);

* }

* @example

* // Example usage with an asynchronous function:

* const asyncResult = await tryCatch(async () => {

* const response = await fetch('https://example.com');

* return response.json();

* });

* if (asyncResult.data) {

* console.log(asyncResult.data);

* } else {

* console.error(asyncResult.error.message);

* }
  */
  export function tryCatch<T, E = Error>(
  arg: Promise | (() => MaybePromise)
  ): Result<T, E> | Promise<Result<T, E>> {
  if (typeof arg === 'function') {
  try {
  const result = arg();
  // If the result is a promise, call tryCatch recursively
  return result instanceof Promise ? tryCatch(result) : { data: result };
  } catch (error) {
  return { error: error as E };
  }
  }

// Handle asynchronous operation with promise chaining return arg .then((data) => ({ data })) .catch((error) => ({ error: error as E })); }

please put it in a code block. this is terrifying

Hey everyone!

Regarding the concern about the error-last pattern:

Value first makes it easier to swallow errors.
IMO, swallowing errors should look uglier)

That's a really valid point. Accidentally ignoring errors is a significant risk.

I've been exploring this and built a utility/tooling combo as a potential solution:

• It enforces that you destructure the result correctly ([data, error] or [data, ,]).
• It flags cases where the result isn't destructured (e.g., const result = tryCatch(...)) or where only data is taken (const [data] = tryCatch(...)), preventing accidental error ignorance.
• It provides real-time feedback and code fixes right in your editor (VS Code, etc.).
• It integrates with tsc (via ts-patch) to catch errors during build/CI.

This way, you can potentially benefit from the scanning readability of having data first, while the tooling ensures errors aren't silently swallowed.

Here's a quick demo of the plugin catching errors and offering fixes:

output.mp4

If you're interested in this approach (Go-style errors made safer with TS tooling), you can check out the repository here:

try-catch-tuple

The README covers the rationale, setup, and usage in more detail.

Note: This is currently a Work in Progress / Proof of Concept. Contributions/feedback are very welcome!

@maxmorozoff well, this approach already posted here by various users including me, however some of them, including me return error first and data second. By doing it this way it slightly easier to destructure since if you only need to check for errors you do const [error] = and if you need only data then const [, data] =

@maxmorozoff, i feel like your utility tool solution is rather overkill given the fact that type completion already fixes this problem: if you tried to destructure it using as [error, data], and checked if error === null, you would realize that data would be Error and that the data variable should come first.

It flags cases where the result isn't destructured (e.g., const result = tryCatch(...)) or where only data is taken (const [data] = tryCatch(...)), preventing accidental error ignorance.

type completion also already does this too. even if you didn't check for an error, data would be Data | null. unless you coerce the type to be always Data (which is a very bad practice), you would always know that data is possible to be nullable.

im going to add a data-first subfunction to my try catch solution if you still want to do it the Go-way, as well as a resolve function as part of the result if you want to extract the data only in a one-liner.

I'm surprised that nobody cares about performance at all.
Every solution is introducing an allocation and an array destruct (which uses iterator) to the success path or allocating an object.

@aquapi nobody is talking about performance because you are not creating a game. you are just writing <100 lines of code for a simple handler for fetching data.

think about this: if you seriously think performance is key, i think there are a million other things in your codebase that will need refactoring in order to cope with your tolerance for speed.

anyways its also not like you are running tryCatch a million times. if you are, you should reconsider how you transfer your data.

@osoclos My point is that you can have faster performance with the same DX.
You are wasting compute for nothing.

@aquapi if you are worried about wasting resources and computation, just use theo's original tryCatch function: it's the most performant and simplest way possible.

if you want to provide the most functionality for devs, i suggest my own version of tryCatch, which has both array and object destructuring, as well as async and non-async function handling.

feel free to criticise my code and we can discuss about improving performance there

@osoclos Let me explain my solution safe-throw:

An example function:

import * as st from 'safe-throw';

const fn = () => Math.random() < 0.5 ? 10 : st.err('Random');

const result = fn();

if (st.isErr(result)) {
  const msg = st.payload(result);
} else {
  // Use result normally
}

• You can type this pretty easily.
• Errors are very lightweight: [errorSymbol, errorPayload] or [errorSymbol, errorPayload, errorTag]
• Use the result directly without any destructuring.
• If you only need error messages there is an even more lightweight form using Symbol that I used for JWT: https://www.npmjs.com/package/fast-crypt#jwt

@aquapi i have a few problems with your solution:

1. having a function to just create an error is rather clunky, especially when import * as st from "safe-throw" now has to be included every time you wanted to throw something.

2. in a large codebase, dev-ex will become severely diminished, since you dont have stack traces using error symbols, and if you use your solution as a very fundamental and core function of your code, and something went wrong with that function when you use it later on, you are likely to suffer since the error cant be natively traced back to the original source, making debugging very difficult.

3. continuing number 2, in more complex functions, the only way to properly use your solution is by having a temporary variable and if it fails, assign your error to it and then return it to prevent further execution. again this is bad dev-ex and you shouldn't need to do this.

@osoclos

1. This is personal preference. Throwing errors are actually much slower (about 300x) and not as type safe as you don't know the error type thrown.
2. You can include stack trace in your error type with a single line: new Error().stack. Some errors don't need a stack trace like errors thrown by a JWT verifier.
3. You can return the error directly: if (st.isErr(result)) return result;

Or if you don't care much about perf and want a nice API:

import * as flow from 'safe-throw/flow';
import * as st from 'safe-throw';
import * as native from 'safe-throw/native';

// Thrown errors will be wrapped with native.err
const asyncFn = native.asyncTry(() => fetch('http://example.com'));
const syncFn = () => Math.random() < 0.5 ? st.err('Random') : 200;

const fn = function*() {
  // Unwrap async and result
  const fetchResult = yield* flow.unwrap(asyncFn());
  const expectedStatus = yield* flow.unwrap(syncFn());
  return fetchResult.status === expectedStatus;
};

const res = await flow.run(fn());
if (st.isErr(res)) {
  // Handle error
} else {
  res; // boolean
}

This project is trying to be neverthrow but faster and uses less memory.

@aquapi

1. i dont think you understand when your code is type-safe. throwing errors will always throw the same error and everything regardless of its type, and the result will be correctly-typed if you checked for errors beforehand.

2. you still have to explicit state that you want a stack trace in your error instead of the solution doing it for you, that's bad dev-ex. when i am writing my app, i dont want to deal with something as trivial as error creation and handling.

@osoclos

1. How do you know if a function throws? With this you always know the result may throw by returning an error (plus it's way faster to not capture stack trace and allocate an Error instance).
2. With this you don't need stack traces. You can always throw if you want to for unrecoverable errors (you should check out neverthrow).

I think just like promises , it might be useful to try catch normal callback functions

export function tryCatchSync<T, E = Error>(callback: () => T): Result<T, E> {
  try {
    const data = callback();
    return { data, error: null };
  } catch (error) {
    return { data: null, error: error as E };
  }
}

So now you can use it like

const {data,error} = tryCatchSync(()=>JSON.parse(someString))

For anyone who just wants to throw this function into their codebase and test it out

export function tryCatch<T, E = Error>(fn: () => T) {
  type Result<TResult, EResult> =
    | { data: TResult; error: null }
    | { data: null; error: EResult };
  type ReturnType =
    T extends Promise<infer P> ? Promise<Result<P, E>> : Result<T, E>;

  try {
    const result = fn();
    if (result instanceof Promise) {
      return result
        .then((data: Promise<unknown>) => ({ data, error: null }))
        .catch((e: unknown) => {
          return { data: null, error: e as E };
        }) as ReturnType;
    } else {
      return { data: result, error: null } as ReturnType;
    }
  } catch (e: unknown) {
    return { data: null, error: e as E } as ReturnType;
  }
}

@osoclos Let me explain my solution safe-throw:

An example function:

import * as st from 'safe-throw';

const fn = () => Math.random() < 0.5 ? 10 : st.err('Random');

The problem here is "how to create a safe wrapper with good DX for outside APIs that can throw". Theo's code is a solution to that. Your code is a way to control errors in your own hand-rolled APIs. These two problems are very much not the same.

@Joseph-Martre it has an API for that

import * as native from 'safe-throw/native';

const safePromise = await native.tryPromise(promise); // T | native.Err
const safeFetch = native.asyncTry(fetch);

This thread nerdsniped me to unify the sync/async methods in my lib: https://github.com/thelinuxlich/go-go-try