Ivan Zaldivar

Posted on Sep 18, 2021 • Edited on Oct 2, 2021

Say goodbye Trycatch Hell

#programming #productivity #typescript #webdev

Hi everyone! It is possible that it is here for the post title, and I daresay you have had problems handling errors with async/await. In this post you will learn a trick to avoid trycatch hell but before, it is neccessary to know a little history.

History of Callback.

Once upon a time, developers had to deal with tasks that took a while, and the way we could check if the task was done was through callback.

Callbacks are nothing more than functions that are executed when a task has been completed, either erroneously or successfully. Until this moment, there is nothing bad. The problem arises when these callbacks in turn execute other functions, and so on. And that's when the macabre happens.

For this reason. Promise are born, as a solution to this problem.

Promises.

The promises are objects that represent the completion of a process, this can be a failure (reject) or a success (resolve). Also, lets add this beauty.

Everything seemed magical, until...

Using async await makes the code more readable, it looks more beautiful, but it has a problem, is that if the promise fails, it will stop the flow of our system, so it is necessary to handle the errors.

But when handling these with trycatch we lose that readability, but don't worry, those are over now my dear friend.

How implemented.

First, we are going to simulate a whole. Let's do it.

We define some interfaces, and add test content.



interface Note {
  id: number;
  name: string;
}

interface Query {
  [key: string]: any;
}

const notes: Note[] = [
  {
    id: 1,
    name: "Megadeth",
  },
  {
    id: 2,
    name: "Korn",
  },
];

We define some functions.



async function update(id: number, data: Omit<Note, "id">, options: Query): Promise<Note> {
  const index: number = notes.findIndex(n => n.id === id);
  if (index < 0) throw new Error("Note does not exist");

  const updated: Note = { id, ...data };
  notes.splice(index, 1, updated);
  return updated;
};

async function remove(id: number, options: Query): Promise<Note> {
  const index: number = notes.findIndex(n => n.id === id);
  if (index < 0) throw new Error("Note does not exist.");

  const note: Note = notes[index];
  notes.splice(index, 1);
  return note;
};

We define our promise handler.



async function promHandler<T>(
  prom: Promise<T>
): Promise<[T | null, any]> {
  try {
    return [await prom, null];
  } catch (error) {
    return [null, error];
  }
}

This function receives a promise as a parameter, then we execute the promise within the trycatch, in order to handle the errors, and we will return an array, in which the first index [0] will be the Response or Result and the second [1] the Error.

Note: You may see a T, this is necessary because we need to know the type of data at all times, they are called generics, if you need to know more, click on the following link: https://www.typescriptlang.org/docs/handbook/2/generics.html

Now, we only consume our handler.



  const [updated, err] = await promHandler(
    update(1, { name: "Mudvayne" }, {})
  );
  // updated -> {id: 1, name: "Mudvayne"}
  // err -> null

  const [removed, error] = await promHandler(remove(4, {}));
  // removed -> null
  // error -> Error "Does not exist."

Now I ask you, does it look better?

Perfect, we already know how to avoid trycatch hell, but this only using promises, what about synchronous functions?

Handling synchronous functions.

We convert our previous functions to synchronous.



function update(id: number, data: Omit<Note, "id">, options: Query): Note {
  // ...
};

function remove(id: number, options: Query): Note {
  // ...
};

We define our synchronous function handler.



function funcHandler<T extends any[], K>(
  func: (...args: T) => K,
  ...params: T
): [K | null, any] {
  try {
    return [func(...params), null];
  } catch (error) {
    return [null, error];
  }
}

Explanation: This function is a bit different than the previous one, since in this one, we have to give it the function (without executing) and the parameters.

This function will have two generics, where T represents the parameters that the function receives, and K the value that it returns. Also, we make use of the spread syntax As we do not know the number of parameters that can reach us, we will make use of these 3 magic points (...) ✨

And now, we carry out the previous process, first index, Result; second indicer, Error. And ready!

We carry out the operations.



  const [updated, err] = funcHandler(update, 1, { name: "Mudvayne" }, {});
  // updated -> {id: 1, name: "Mudvayne"}
  // err -> null

  const [removed, error] = funcHandler(remove, 6, {});
  // removed -> null
  // error -> Error "Does not exist."

Great, we no longer have to struggle to make our code look more readable, and also, we reuse the handles.

You know, if you have something to contribute, a question, an improvement, you can contribute in the comments, and if it has been useful, leave your reaction, that makes me happy.

Follow me on social networks.

🎉 Twitter: https://twitter.com/ToSatn2
💡 Github: https://github.com/IvanZM123

Top comments (32)

Oyster Lee • Sep 19 '21

This is over-engineered to me

Pedro M. M. • Sep 20 '21 • Edited

Actually, this error tuple-pattern is very common in Go.

if x, err := doSomething(); err != nil {
   // failed!
}
// worked! Safe to use x.

x, err := doSomething()
if err != nil {
  // failed!
}
// worked! Safe to use x

x, err := doSomething(); err == nil {
  // Do something with x only if doSomething() returns no errors
}

if x, ok := booleanOp(); ok {
    // Do something with x only if ok = true
}

In terms of error handling, my favorite is rust because it has less overhead. But it's uglier and a little bit more complicated.

Oyster Lee • Sep 20 '21

Yes, I am a gopher, but do you think over 50% JavaScript developer using Go?

Pedro M. M. • Sep 21 '21 • Edited

No! Of course not lol.

My point was — If a whole modern language, which is known as an easy-to-read language, uses a pattern like that as standard good practice maybe the pattern is not that over-engineered

Ivan Zaldivar • Sep 20 '21

It seems like this at first glance, but it will be useful when the use of trycatch becomes repetitive, and these functions allow you to always reuse them.

Sanna Jammeh • Sep 19 '21

It's a great solution, but it can be made even simpler. You will need another if statement to handle errors in your example. Why not just check if the promise is an error instance.

const res = await (promise).catch((e) => e).

If(res instanceof Error) {
// Handle err
}

Ivan Zaldivar • Sep 20 '21

Mm... I've never thought about it, I like your solution. Thanks!

Szymon Dziewoński • Dec 30 '21

this exactly how I catch errors, and I was wondering whole time reading article "why is there a problem?" However I like wrapper util :)

Kristiqn Tachev • Sep 20 '21 • Edited

You need to catch exceptions on the top level of the function and try not to use the try catch scope until you need to re throw something specific.

With the following approach we are hiding unhandled rejections by providing status code 500 (Database errors for example) and only the correct thrown exceptions will be shown as a result of the requester.

import { randomBytes } from "crypto";

const generateUID = () => randomBytes(8).toString("hex");

/* @HttpCodes
 * Partial list of http codes
 */
export enum HttpCodes {
  Ok = 200,
  Redirect = 302,
  BadRequest = 400,
  Unauthorized = 401,
  PaymentRequired = 402,
  Forbidden = 403,
  NotFound = 404,
  MethodNotAllowed = 405,
  NotAcceptable = 406,
  ProxyAuthenticationRequired = 407,
  RequestTimeout = 408,
  Conflict = 409,
  Gone = 410,
  LengthRequired = 411,
  PreconditionFailed = 412,
  PayloadTooLarge = 413,
  URITooLong = 414,
  UnsupportedMediaType = 415,
  RangeNotSatisfiable = 416,
  ExpectationFailed = 417,
  ImATeapot = 418,
  MisdirectedRequest = 421,
  UnprocessableEntity = 422,
  Locked = 423,
  FailedDependency = 424,
  UnorderedCollection = 425,
  UpgradeRequired = 426,
  PreconditionRequired = 428,
  TooManyRequests = 429,
  RequestHeaderFieldsTooLarge = 431,
  UnavailableForLegalReasons = 451,
  InternalServerError = 500,
  NotImplemented = 501,
  BadGateway = 502,
  ServiceUnavailable = 503,
  GatewayTimeout = 504,
  HTTPVersionNotSupported = 505,
  VariantAlsoNegotiates = 506,
  InsufficientStorage = 507,
  LoopDetected = 508,
  BandwidthLimitExceeded = 509,
  NotExtended = 510,
  NetworkAuthenticationRequired = 511,
}

/* @HttpError
 * Main generic http status error handler
 */
export class HttpError extends Error {
  public reason?: string;
  public isCustomError? = true;
  constructor(
    public readonly message: string | never,
    public readonly statusCode: HttpCodes,
    public readonly details?: object,
  ) {
    super(message);
    this.name = HttpCodes[statusCode];
    this.message = message;

    /* When message is different than status text we have a custom message reason */
    if (HttpCodes[statusCode] !== message) {
      this.reason = message;
    }
  }
}

/* @HttpCodeEnumType
 * Generic enumerable for strict checking of all http codes
 * example: throw HttpErrors.Unauthorized()
 */
export type HttpCodeEnumType<T, K> = {
  [key in keyof typeof HttpCodes]: (
    message?: T,
    details?: object | undefined,
  ) => K;
};

/* @HttpErrors
 * Record of httpErrors
 * example: throw HttpErrors.Unauthorized()
 */
export const HttpErrors: HttpCodeEnumType<string, HttpError> = Object.values(
  HttpCodes,
)
  .filter(k => typeof HttpCodes[k as never] === 'number')
  .reduce((codes, code) => ({
      ...codes,
      [code]: (message = code as never, details: never) =>
        new HttpError(message, HttpCodes[code as never] as never, details),
    }), {} as HttpCodeEnumType<string, HttpError>);


async function myAsyncFunctionNext() {
  return 1;
}
async function myAsyncFunctionNext2() {
  return 2;
}
async function myAsyncFunctionNext3() {
  throw HttpErrors.BadGateway()
  return 3;
}

async function myAsyncFunctionNext4() {
  throw new Error('unauthorized')
}


async function myAsyncFunction() {
  await myAsyncFunctionNext();
  await myAsyncFunctionNext2();
  await myAsyncFunctionNext3();
  // Only try catch if you really want to change the error from specific message thrown
  try {
    await myAsyncFunctionNext4()
  } catch (e) {
    if (e.message === 'unauthorized') {
      throw HttpErrors.Unauthorized()
    }
    throw e;
  }
  return 'successs';
}

export async function handler() {
  try {
    return {
      statusCode: 200,
      body: await myAsyncFunction()
    }
  } catch (e) {
    if (e.isCustomError) {
      return {
        statusCode: e.statusCode,
        body: JSON.stringify(e),
      };
    }

    const uuid = [generateUID(), "-", generateUID(), "-", generateUID()].join(
      ""
    );
    console.error(`[${uuid}]:`, e);
    return {
      statusCode: 500,
      body: JSON.stringify({
        name: "InternalServerError",
        details: { uuid },
      }),
    };
  }
}

Anton Trofimenko • Sep 22 '21 • Edited

Done years ago of.js.org

Laurent Perroteau • Sep 22 '21

Another exemple : await-to-js that returns the error first to enforce it to be handled :

const [error, result] = await to(getList());

if (error) ...

Daniel Hillmann • Dec 14 '21 • Edited

Was about to point out it all seemed a bit like re-inventing the wheel, considering modules like this already exist.

I personally use and like await-to-js for many use cases.

Ivan Zaldivar • Sep 22 '21

I like, but is not necessary why is Typescript being used (as long as the developer uses static typing)

Alex Lohr • Sep 22 '21

There's a simple solution. Whatever you await should usually return a promise and thus can be directly caught:

// Don't
try {
  await myAsyncFn();
} catch(e) {
  console.error(e);
}

// Do
await myAsyncFn().catch(console.error);

Ivan Dilber • Sep 23 '21

Completely pointless refactor exercise IMHO, as now instead of try/catch-ing you need to check each time if a function returned an error or not.

When an exception is thrown it will jump out of all blocks, so there's no need to catch it at the same level. You can set just a single try/catch block on the parent (or even higher) scope to catch all of them.

Gers2017 • Sep 20 '21 • Edited

I usually do

async function handleRequest(req: Response, res: Request){
   const {user, error} = await getUserData(1);
   if(error){
       return res.status(400).json({error})
   }
   res.status(200).json({user})
}

interface UserData{
    name:string
    age: number
}

type UserResponse = { user: UserData | null, error: string | null }
async function getUserData(id: number): Promise<UserResponse>{
    if(id <= 0){
        return {
            user: null,
            error: "Wrong, id can't be less or equal to zero!!!" // Why this failed
        }
    }
    return {
        user: {name: "Jimmy", age: 22},
        error: null
    }
}

Or I'd just throw an error inside the getUserData function

async function handleRequest(){
    try{
        const { user } = await getUserData(1);
        const { user: user2 } = await getUserData(1);
        console.log(user, user2);
    }
    catch(e){
        console.error(e);
    }
}

interface UserData{
    name:string
    age: number
}

type UserResponse = { user: UserData | null }
async function getUserData(id: number): Promise<UserResponse>{
    if(id <= 0){
        throw Error("Wrong, id can't be less or equal to zero!!!")
    } else {
        return { user: {name: "Jimmy", age: 22} }
    }
}

Ivan Zaldivar • Sep 20 '21

Thank you for your contribution, my friend.

Personally, I do not like to handle errors that way, I consider them incorrect, I leave you the link so you can take a look about making these exceptions: developer.mozilla.org/docs/Web/Jav...

async function getUser(id: number): Promise<User> {
  // We throw an exception.
  if (id <= 0) throw new Error("Wrong, id can't be less or equal to zero!!!");
  // Result.
  return { id, email: "abc@domain.com" };
}

Now we handle it.

async function handleRequest(req: Request, res: Response) {
  const [user, err] = await promHandler(getUser(Number(req.params.id)));
  if (!user || err) return res.status(400).json({
    name: "BadRequest",
    message: err.message
  });
  res.status(200).json(user);
}

Gers2017 • Sep 21 '21

Sure, I actually like the golang pattern because is easy to read.
Also I got a different approach by asking about this.

type Result<T> = 
{ result: T, error?: undefined } ||  
{ result?: undefined, error: Error }

async function getUserData(id: number): Promise<Result<UserData>>{
    if(id <= 0){
        return {
            error: new Error("Wrong, id can't be less or equal to zero!!!");
        }
    }
    return {
        result: {name: "Jimmy", age: 22},
    }
}

Валерий Кулаков • Sep 26 '21

First, you have not avoided the problem, because now You have to write some if (error) in the code, and it will be even worse.
Moreover, in fact, we most likely need a global error handler.

vnues • Sep 23 '21 • Edited

This is too complicated, I usually do this

const to = (promise: any) => {
  if (!promise) {
    return new Promise((resolve, reject) => {
      reject(new Error('requires promises as the param'))
    }).catch((err: Error) => {
      return [err, null]
    })
  }
  return promise
    .then(function() {
      const arr = Array.from(arguments)
      return [null, ...arr]
    })
    .catch((err: Error) => {
      return [err, null]
    })
}

export const exec = async (sql: string) => {
  const [err, res] = await to(db.exec(sql))
  if (err) {
    throw new Error(err)
  }
  return res
}

// ...async function 
const [data,err] = await to(getUsers())