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

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