2022-04-05
1971
#vanilla javascript
Vijit Ail
101953
Apr 5, 2022 ⋅ 7 min read

How to write a declarative JavaScript promise wrapper

Vijit Ail Software Engineer at toothsi. I work with React and NodeJS to build customer-centric products. Reach out to me on LinkedIn or Instagram.

Recent posts:

open ai agent kit

I tried OpenAI’s AgentKit: Does it make Zapier and n8n obsolete?

Examine AgentKit, Open AI’s new tool for building agents. Conduct a side-by-side comparison with n8n by building AI agents with each tool.

Clara Ekekenta
Nov 4, 2025 ⋅ 11 min read

A Jarvis for everyone: AI agents as new interfaces

AI agents powered by MCP are redefining interfaces, shifting from clicks to intelligent, context-aware conversations.

Peter Aideloje
Nov 4, 2025 ⋅ 10 min read
Why Frontend Devs Should Care About Platform Engineering

Why frontend devs should care about platform engineering

Learn how platform engineering helps frontend teams streamline workflows with Backstage, automating builds, documentation, and project management.

Muhammed Ali
Nov 3, 2025 ⋅ 6 min read
vercel ai elements featured image

How I built an AI productivity assistant with Vercel AI Elements

Build an AI assistant with Vercel AI Elements, which provides pre-built React components specifically designed for AI applications.

Emmanuel John
Nov 3, 2025 ⋅ 9 min read
View all posts

2 Replies to "How to write a declarative JavaScript promise wrapper"

  1. Another way to handle the try catch if/else is to use the await keyword but use .catch on that promise if you don’t want the outer try catch involved. You can also handle it in the .catch and also re throw it if you would want to halt the execution flow.

    try {
    // business logic includes exception so nds particular handling
    const data = await something()
    .catch(th => {
    // process exception
    // rethrow if some condition
    });
    // only caught by outer bc it’s a zero sum expectation for example
    const more = await someone();
    } catch (th) {
    // handle th
    }

  2. The approach is similar to monad-transformer TaskEither

    https://gcanti.github.io/fp-ts/modules/TaskEither.ts.html

    Actually there is a significant difference between Either.Left and Exception.

    The first one should be used for “recovable” errors, the second one — for unrecoverable.

    So it means we don’t need to avoid throwing an exception in all cases, replacing them with error-result tuple. And the promiser can help with that.

    Nevertheless, the movement to functional programming is great.

Leave a Reply

Would you be interested in joining LogRocket's developer community?

Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.

Sign up now