In certain scenarios like Promise or exception throws where setting error types is not possible, handling errors in a Rust-like style can be beneficial:

// Result<T, E> is the type used for returning and propagating errors.
// It is a sum type with two variants:
// Ok<T>, representing success with a value, and 
// Err<E>, representing an error with an error value.
export type Ok<T> = { _tag: "Ok"; ok: T };
export type Err<E> = { _tag: "Err"; err: E };
export type Result<T, E> = Ok<T> | Err<E>;
export const Result = Object.freeze({
  Ok: <T, E>(ok: T): Result<T, E> => ({ _tag: "Ok", ok }),
  Err: <T, E>(err: E): Result<T, E> => ({ _tag: "Err", err }),
});

const start = (): Promise<Result<string, number>> => {
  return new Promise((resolve) => {
    resolve(someCondition ? Result.Ok("correct!") : Result.Err(-1));
  });
};

start().then((r) => {
  switch (r._tag) {
    case "Ok": {
      console.log(`Ok { ${r.ok} }`);
      break;
    }
    case "Err": {
      console.log(`Err { ${r.err} }`);
      break;
    }
  }
});

When it comes to exceptions, the typed any is necessary because we can't always be sure of the correct type of exception during design time. Unfortunately, both TypeScript and JavaScript lack the capability to safeguard exception types at runtime. The most effective solution is to implement type guards in order to perform checks at both design-time and run-time in your code.

source

Here's my interpretation of it:

declare class CustomErrorPromise<TSuccess, TError> extends Promise<TSuccess> {
    constructor(executor: (resolve: (value: TSuccess | PromiseLike<TSuccess>) => void, reject: (reason: TError) => void) => void) {
        super(executor);
        // Object.setPrototypeOf(this, new.target.prototype);  // restore prototype chain
    }
}

export interface CustomErrorPromise<TSuccess, TError = unknown> {
    then<TResult1 = TSuccess, TResult2 = never>(onfulfilled?: ((value: TSuccess) => TResult1 | PromiseLike<TResult1>) | undefined | null, onrejected?: ((reason: TError) => TResult2 | PromiseLike<TResult2>) | undefined | null): Promise<TResult1 | TResult2>;

    catch<TResult = never>(onrejected?: ((reason: TError) => TResult | PromiseLike<TResult>) | undefined | null): Promise<TSuccess | TResult>;
}

Implement it in your code:

return new CustomErrorPromise<T, ExecError>((resolve, reject) => { ... })

Your text editor should recognize the type of reject:

https://i.sstatic.net/2pjzb.png

https://i.sstatic.net/iSSmo.png

As stated by @EstusFlask in their response, the information provided is accurate.

However, I am interested in exploring an artificial solution to simulate the desired outcome using TypeScript features.

Occasionally, I implement this approach in my codebase 😊:

interface IMyEx{
   errorId:number;
}

class MyEx implements IMyEx{
   errorId:number;
   constructor(errorId:number) {
      this.errorId = errorId;
   }
}
// -------------------------------------------------------
var prom = new Promise(function(resolve, reject) {
     try {
         if(..........)
            resolve('Huuuraaa');         
         else
            reject(new MyEx(100));
     }
     catch (error) {
            reject(new MyEx(101));
     }
});

// -------------------------------------------------------
prom()
.then(success => {
    try {
        }
    catch (error) {
        throw new MyEx(102);
    }
})
.catch(reason=>{
    const myEx = reason as IMyEx;
    if (myEx && myEx.errorId) {
       console.log('known error', myEx)
    }else{
       console.log('unknown error', reason)
    }
})

One way to ensure the argument types of resolve and reject in JavaScript is to use a proxy. In the example below, there is no attempt to simulate the promise constructor, as the focus is on enabling calling .resolve() and .reject() as standalone functions. On the consuming end, the naked promise is utilized with syntax like

await p.promise.then(...).catch(...)

export type Promolve<ResT=void,RejT=Error> = {
  promise: Promise<ResT>;
  resolve: (value: ResT | PromiseLike<ResT>) => void;
  reject: (value: RejT) => void
};

export function makePromolve<ResT=void,RejT=Error>(): Promolve<ResT,RejT> {
  let resolve: (value: ResT | PromiseLike<ResT>) => void = (value: ResT | PromiseLike<ResT>) => {}
  let reject: (value: RejT) => void = (value: RejT) => {}
  const promise = new Promise<ResT>((res, rej) => {
    resolve = res;
    reject = rej;
  });
  return { promise, resolve, reject };
}

While the let statements may seem redundant at runtime, they serve the purpose of preventing compiler errors that are otherwise difficult to resolve.

(async() => {
  const p = makePromolve<number>();
  //p.resolve("0") // compiler error
  p.resolve(0);
  // p.reject(1) // compiler error 
  p.reject(new Error('oops')); 

  // simply use the named promise without enforcing types on the receiving end
  const r = await p.promise.catch(e=>e); 
})()

By following this approach, calls to .resolve and .reject can be dynamically checked for correct types.

In contrast, no effort is made here to impose type checking on the receiving side. While exploring this idea, adding .then and .catch members raised questions about returning values. Should they return a Promise, it would revert back to a standard promise operation. As a result, sticking to using the naked promise for operations like await, .then, and .catch seems most practical.

My approach to the problem is as follows:

To tackle this issue, I propose creating a new type that extends both the original PromiseConstructor and Promise:

interface CustomPromiseConstructor<ResolvedType, RejectedType> extends PromiseConstructor {
  /**
   * Constructs a new Promise.
   * @param executor A function used to initialize the promise. This function takes two parameters:
   * a resolve callback function to fulfill the promise with a value or another promise's result,
   * and a reject callback function to reject the promise with an error or reason.
   */
  new <T = ResolvedType, R = RejectedType>(
    executor: (resolve: (value: T | PromiseLike<T>) => void, reject: (reason?: R) => void) => void
  ): CustomPromise<T, R>;
}

interface CustomPromise<ResolvedType, RejectedType> extends Promise<ResolvedType> {
  /**
   * Registers a handler for when the Promise rejects.
   * @param onrejected The function to execute upon rejection of the Promise.
   * @returns A Promise representing the completion of the handler.
   */
  catch<TResult = never>(
    onrejected?: ((reason: RejectedType) => TResult | PromiseLike<TResult>) | undefined | null
  ): CustomPromise<ResolvedType | TResult>;

  /**
   * Attaches callbacks for the resolution and/or rejection of the Promise.
   * @param onfulfilled The callback to execute when the Promise resolves.
   * @param onrejected The callback to execute when the Promise rejects.
   * @returns A Promise representing the completion of either callback.
   */
  then<TResult1 = ResolvedType, TResult2 = never>(
    onfulfilled?: ((value: ResolvedType) => TResult1 | PromiseLike<TResult1>) | undefined | null,
    onrejected?: ((reason: RejectedType) => TResult2 | PromiseLike<TResult2>) | undefined | null
  ): Promise<TResult1 | TResult2>;
}

We can now proceed to transform instances of the Promise type into those of the CustomPromiseConstructor during implementation:

const promise = new (Promise as CustomPromiseConstructor<number, Error>)((resolve, reject) => {
  if (Date.now() % 2 === 0) {
    reject(new Error(`Worker terminated with exit code: 1`));
  } else {
    resolve(0);
  }
});

My approach to solving this (similar to @moontai0724) was as follows:

// typed-promise.d.ts

interface TypedPromise<RESOLVE, REJECT> extends Promise<RESOLVE> {

  then<TResult1 = RESOLVE, TResult2 = never>(
      onfulfilled?: (((value: RESOLVE) => (TResult1 | PromiseLike<TResult1>)) | undefined | null),
      onrejected?: (((reason: (REJECT | any)) => (TResult2 | PromiseLike<TResult2;)) | undefined |null)
  ): TypedPromise<TResult1 | TResult2>;

  catch<TResult = never>(onrejected?: (((reason: (REJECT | any)) => (TResult | PromiseLike<TResult>)) | undefined | null): TypedPromise<RESOLVE | TResult>;

  finally(onfinally?: ((() => void) | undefined | null)): TypedPromise<RESOLVE | REJECT>;

}

// typed-promise-constructor.d.ts

interface TypedPromiseConstructor<RESOLVE, REJECT> extends PromiseConstructor {

  new<RES = RESOLVE, REJ = REJECT>(
      executor: ((resolve: ((value: (RES | PromiseLike<RES>)) => void), reject: ((reason?: REJ) => void)) => void)
  : TypedPromise<RES, REJ>;
}

declare var TypedPromise: TypedPromiseConstructor;

If you stumbled upon this page while searching on google, although not directly related to the original question, I believe it is still worth mentioning.

I recently faced a scenario where I needed TypeScript to recognize that a promise would only reject, particularly when using Promise.race for timeouts. This can be achieved by simply specifying the return type as never. TypeScript will then interpret that the promise will ONLY result in rejection.

Here is an example to illustrate:

const timeout = new Promise<never>((resolve, reject) => {
    setTimeout(() => {
        reject(new Error('Cache timed out after 10 seconds'));
    }, 10000);
});
const result = await Promise.race([
    cache.searchCache(key),
    timeout
]);