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 };
  }
}

i made a npm package which is basically just theo's version but with added support for sync functions
npmjs.com/package/typecatch

This would work better if it returned undefined on error, so you could use a default value shorthand when spreading an object.

update to 0.2.2 :)

How do I make it work for passing in a arrow function with an await inside of it, for example:

onst { data: uploadInsertResult, error: uploadInsertError } = await tryCatch(
    async () => {
      const result = await archeWebDb
        .insert(uploads)
        .values({
          uploadName: file.name,
          saveDirectory: env.UPLOADS_DIR,
          extension: extension,
        })
        .$returningId(); // This line should not be followed by a comma

      return result;
    },
  );

type Success<T> = readonly [null, T]
type Failure<E> = readonly [E, null]
type ResultSync<T, E> = Success<T> | Failure<E>
type ResultAsync<T, E> = Promise<ResultSync<T, E>>
type Operation<T> = Promise<T> | (() => T) | (() => Promise<T>)

export function tryCatch<T, E = Error>(operation: Promise<T>): ResultAsync<T, E>
export function tryCatch<T, E = Error>(operation: () => Promise<T>): ResultAsync<T, E>
export function tryCatch<T, E = Error>(operation: () => T): ResultSync<T, E>
export function tryCatch<T, E = Error>(operation: Operation<T>): ResultSync<T, E> | ResultAsync<T, E> {
  if (operation instanceof Promise) {
    return operation.then((data: T) => [null, data] as const).catch((error: E) => [error as E, null] as const)
  }

  try {
    const result = operation()

    if (result instanceof Promise) {
      return result.then((data: T) => [null, data] as const).catch((error: E) => [error as E, null] as const)
    }

    return [null, result] as const
  } catch (error) {
    return [error as E, null] as const
  }
}

const [error, data] = await tryCatch(async () => {
  const [file] = await db
    .insert(filesTable)
    .values({ size: 1234, mimeType: "text/plain", path: "/uploads/test.txt" })
    .returning()

  if (!file) {
    throw new Error("File creation failed")
  }

  return file
})

if (error) {
  console.error("Error creating the file:", error)
  // Handle the error
  throw error
}

console.log(data)

I used the code above as a baseline and made some adjustments to better suit my needs. I also addressed a few additional edge cases—for example, adding an overload for the never type to prevent the Promise-specific overload from being incorrectly used. Additionally, I use isPromise utility to ensure compatibility with external promises. This was particularly helpful in resolving issues I encountered when returning a PrismaPromise without awaiting it first.

Additionally, you could implement support for a second argument—such as a transformError function—to wrap or customize internal errors. This allows for more flexible error handling, especially when you want to add context or standardize error formats.

export type OperationSuccess<T> = readonly [data: T, error: null];
export type OperationFailure<E> = readonly [data: null, error: E];
export type OperationResult<T, E> = OperationSuccess<T> | OperationFailure<E>;

type Operation<T> = Promise<T> | (() => T) | (() => Promise<T>);

export function trycatch<T, E = Error>(operation: Promise<T>): Promise<OperationResult<T, E>>;
export function trycatch<T, E = Error>(operation: () => never): OperationResult<never, E>;
export function trycatch<T, E = Error>(operation: () => Promise<T>): Promise<OperationResult<T, E>>;
export function trycatch<T, E = Error>(operation: () => T): OperationResult<T, E>;
export function trycatch<T, E = Error>(
    operation: Operation<T>,
): OperationResult<T, E> | Promise<OperationResult<T, E>> {
    try {
        const result = typeof operation === 'function' ? operation() : operation;

        if (isPromise(result)) {
            return Promise.resolve(result)
                .then((data) => onSuccess(data))
                .catch((error) => onFailure(error));
        }

        return onSuccess(result);
    } catch (error) {
        return onFailure<E>(error);
    }
}

const onSuccess = <T>(value: T): OperationSuccess<T> => {
    return [value, null];
};

const onFailure = <E>(error: unknown): OperationFailure<E> => {
    const errorParsed = error instanceof Error ? error : new Error(String(error));
    return [null, errorParsed as E];
};

const isPromise = <T = any>(value: unknown): value is Promise<T> => {
    return (
        !!value &&
        (typeof value === 'object' || typeof value === 'function') &&
        typeof (value as any).then === 'function'
    );
};

// ---------------------------
// Testing
// ---------------------------

const main = async () => {
    const syncCallback = () => 'data';
    const asyncCallback = async () => 'data';
    const promise = new Promise<string>((resolve) => resolve('data'));

    const [syncCallbackResult, syncCallbackError] = trycatch(syncCallback);
    const [asyncCallbackResult, asyncCallbackError] = await trycatch(asyncCallback);
    const [promiseResult, promiseError] = await trycatch(promise);
};

For anyone using Drizzle you should add .execute() to the end of your query

For anyone using Drizzle you should add .execute() to the end of your query

Isn't execute only for raw queries?

I couldn't find an information in the docs about it but here it is being used 👇. It is different than db.execute() https://orm.drizzle.team/docs/latest-releases/drizzle-orm-v0110

…

On Tue, Jun 17, 2025, 3:06 AM Lucas Cândido ***@***.***> wrote: ***@***.**** commented on this gist. ------------------------------ For anyone using Drizzle you should add .execute() to the end of your query Isn't execute only for raw queries? — Reply to this email directly, view it on GitHub <https://gist.github.com/t3dotgg/a486c4ae66d32bf17c09c73609dacc5b#gistcomment-5620154> or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJBP55VUIUH4NI7UR6D2PR33D5LZPBFKMF2HI4TJMJ2XIZLTSKBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDHNFZXJJDOMFWWLK3UNBZGKYLEL52HS4DFVRZXKYTKMVRXIX3UPFYGLK2HNFZXIQ3PNVWWK3TUUZ2G64DJMNZZDAVEOR4XAZNEM5UXG5FFOZQWY5LFVEYTGNRVGEYTEOJWU52HE2LHM5SXFJTDOJSWC5DF> . You are receiving this email because you commented on the thread. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .

I couldn't find an information in the docs about it but here it is being used 👇. It is different than db.execute() orm.drizzle.team/docs/latest-releases/drizzle-orm-v0110
…
On Tue, Jun 17, 2025, 3:06 AM Lucas Cândido @.> wrote: @.* commented on this gist. ------------------------------ For anyone using Drizzle you should add .execute() to the end of your query Isn't execute only for raw queries? — Reply to this email directly, view it on GitHub https://gist.github.com/t3dotgg/a486c4ae66d32bf17c09c73609dacc5b#gistcomment-5620154 or unsubscribe https://github.com/notifications/unsubscribe-auth/AJBP55VUIUH4NI7UR6D2PR33D5LZPBFKMF2HI4TJMJ2XIZLTSKBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDHNFZXJJDOMFWWLK3UNBZGKYLEL52HS4DFVRZXKYTKMVRXIX3UPFYGLK2HNFZXIQ3PNVWWK3TUUZ2G64DJMNZZDAVEOR4XAZNEM5UXG5FFOZQWY5LFVEYTGNRVGEYTEOJWU52HE2LHM5SXFJTDOJSWC5DF . You are receiving this email because you commented on the thread. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .

It's probably only a vestigial API and it's not necessary anymore for a long time, otherwise it would be found somewhere in the docs. So why did you believe execute is important in select, insert, delete, findFirst, findMany, etc. methods?

I was getting an error inside of the tryCatch function. It was something like operation is not a function or something like that. So . execute solved it for me. Edit: - Though it is better to handle this in the tryCatch function. Edit 2: Drizzle has an interesting (at least to me) implementation where if you don’t await, it returns a builder. If you do await, it becomes a Promise. More info about [Thenables (MDN) ](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise#thenables) The issue was that I was calling operation(), which returned a builder, not a Promise. So if I’m not wrong, inside the tryCatch block, if I wrap the result with Promise.resolve, it should work. ```ts const query = new FakeQuery(['user1', 'user2']); // Treated like a builder console.log('Query object:', query); // Auto-executes on await const result = await query; console.log('Result:', result); ```

I was getting an error inside of the tryCatch function. It was something like operation is not a function or something like that. So . execute solved it for me. Edit: - Though it is better to handle this in the tryCatch function. Edit 2: Drizzle has an interesting (at least to me) implementation where if you don’t await, it returns a builder. If you do await, it becomes a Promise. More info about Thenables (MDN) The issue was that I was calling operation(), which returned a builder, not a Promise. So if I’m not wrong, inside the tryCatch block, if I wrap the result with Promise.resolve, it should work. ts const query = new FakeQuery(['user1', 'user2']); // Treated like a builder console.log('Query object:', query); // Auto-executes on await const result = await query; console.log('Result:', result);

So it's related to the fixes @nazarEnzo applied a few comments above, where he passed the promises to Promise.resolve method. I still haven't used the tryCacth function with any prisma promise yet, but when I do, I'll come back here if any issue arises.

FYI: My initial answer code wasn't actually working properly for synchronous operations, because the return was always a Promise. Now this is fixed by using custom isPromise utility (to support non-native promises). Promise.resolve().then() can totally be replaced with .then()

/**
 * Checks if the value is a Promise
 * @param value - The value to check
 * @returns True if the value is a Promise, false otherwise
 */
export function isPromise<T = any>(value: unknown): value is Promise<T> {
    return (
        !!value &&
        (typeof value === 'object' || typeof value === 'function') &&
        typeof (value as any).then === 'function'
    );
}

// ----------------
// Test
// ----------------

import prismaClient from 'database/prismaClient';

const userPromise = prismaClient.user.findFirst();

console.log(
    userPromise instanceof Promise, // false
    isPromise(userPromise) // true
);

Love the approach, but I think T3’s solution has a couple of type-safety concerns:

1. null values introduce ambiguity — If null is a valid return type for your promise, then both Success and Failure could have data: null, which makes narrowing unreliable and weakens type safety.
2. Casting the error is unsafe — The generic E looks flexible, but it actually opens you up to runtime issues. If you specify an arbitrary error type that doesn’t match what’s truly thrown, TypeScript will happily assume it’s correct. At runtime, that can lead to property access errors (error.name, etc.) that the type checker can’t catch.

Here’s how I implemented it instead:

type TryCatchSuccess<T> = { success: true, data: T }
type TryCatchError = { success: false, error: unknown }
type TryCatchResult<T> = TryCatchSuccess<T> | TryCatchError;

const tryCatch = async <T>(operation: () => Promise<T>): Promise<TryCatchResult<T>> => {
	try {
		const data = await operation();
		return { success: true, data }
	} catch(error) {
		return { success: false, error }
	}
};

This approach avoids unsafe casts, uses a clear boolean discriminator for type narrowing, and properly treats errors as unknown — the most type-safe way to handle thrown values in TypeScript.

Your application code then is required to do type guards / narrowing to properly type the error:

const result = await tryCatch(async () => {
	// return promise
});

if(result.success) {
	// handle success
} else {
	if(result.error instanceof MyError) {
		// handle MyError
	} else {
		// handle other errors
	}
}