Skip to content

Instantly share code, notes, and snippets.

@t3dotgg
Last active November 30, 2025 20:25
Show Gist options
  • Select an option

  • Save t3dotgg/a486c4ae66d32bf17c09c73609dacc5b to your computer and use it in GitHub Desktop.

Select an option

Save t3dotgg/a486c4ae66d32bf17c09c73609dacc5b to your computer and use it in GitHub Desktop.
Theo's preferred way of handling try/catch in TypeScript
// 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 };
}
}
@nazarEnzo
Copy link

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

@rkingon
Copy link

rkingon commented Oct 17, 2025

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment