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:

How To Iterate Over Enums In TypeScript

How to iterate over enums in TypeScript (with code examples)

Learn exactly how to iterate over numeric and string enums in TypeScript, with practical code snippets and type-safe patterns.

Matteo Di Pirro
Jun 2, 2025 â‹… 9 min read
How To Import SVGs Into Your Next.js Apps

How to import SVGs into your Next.js apps: A 2025 guide

Learn the best 2025 methods to import SVGs in Next.js 14+, with tips on performance, styling, and App Router integration.

Joseph Mawa
Jun 2, 2025 â‹… 9 min read
designing llm first products

Designing LLM-first products, not just features

Everyone’s building chat-first AI products. And most of them suck. Here’s how to break the mold and ship LLM-native software that actually solves problems.

Rosario De Chiara
May 30, 2025 â‹… 4 min read
Build A React AI Image Generator With Hugging Face Diffusers

Build a React AI image generator with Hugging Face Diffusers

Build a React-based AI image generator app offline using the Hugging Face Diffusers library and Stable Diffusion XL.

Andrew Baisden
May 29, 2025 â‹… 10 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