Idiomatic promise handling?

[aThorp96]

Coming from Rust to Typescript I was very happy to find this library. I am having a hard time finding an idiomatic way to combine usage of the Result type and Promises. E.g. I have a function which necessarily has to be async, is it more idiomatic to use the Promise's native error handling? I want to treat the result as a monad, but having them nested promise monad feels like I'm working against something, which tells me I'm probably using it wrong 😄

Below is an example of an async work function and a consumer of the function which shouldn't return a result, but necessarily has to be a promise.

async function someAsyncCall(): Promise<string> {
    throw new Error("how does this get handled alongside the Result.Err?");
}

async function tryWork() -> Result<string, Error> {
    try {
        const workResult: string = await someAsyncCall();
        return Result.ok(`work '${workResult}' was done`);
    } catch (e) {
        return Result.err(e);
    }
}

async function maybeWorkDone() -> Maybe<string>
    try {
        const result = (await tryWork()).unwrapOrElse((e) -> throw e);
        return Maybe.of(result);
    } catch (e) {
        console.error('encountered error working`, e);
        return Maybe.nothing();
    }
}

The issue to be clear is combining the failure modes of the async failing via Promise.reject with the Result.Err; both have to be handled in order to treat the code as safe, but it's unclear if there is a good way to do so 😕

[chriskrycho]

Yeah, this is an unfortunate reality of working with Promise in general: its lack of clear handling on the error case itself is really frustrating, but falls out organically from the way that .catch() was designed to interoperate with throw. I wrote up some related notes over on #430, but those don't really get at the thing you're describing here.

Ultimately, I still think a Task-like API (#25, #215) would be the "right" way to handle this, but it's not trivial to get right and neither @bmakuh nor I have had time to fully tackle that.

In the specific example you offer here, there are a couple things to notice:

1. First, the return type from an async function must be Promise<T> in TypeScript. This is actually analogous to Rust, where the -> impl Future is implied, but is still part of the type signature and therefore shows up in compiler messages etc. That means that your types will have to be Promise<Result<string, Error>> or Promise<Maybe<string>> in the functions as you have them.

2. Instead of throwing in error cases, once you have wrapped things up into a Result (i.e. handled the Promise rejection), you can continue operating with the other Result and Maybe helper functions ("combinators").

3. Because True Myth really leans into a more “functional” idiom, I find it much easier to work with the Promise .then()/.catch() style in many cases, rather than try/catch.

Putting those three things together, here's how I might rewrite your example:

function tryWork(): Promise<Result<string, Error>> {
  return someAsyncCall().then(
    (value) => Result.ok(value),
    (cause) => {
      let error =
        cause instanceof Error
          ? cause
          : new Error("failed async call", { cause });
      return Result.err(error);
    }
  );
}

async function maybeWorkDone(): Promise<Maybe<string>> {
  let result = await tryWork();
  return result.match({
    Ok: (value) => Maybe.just(value),
    Err: (e) => {
      console.error("encountered error working", e);
      return Maybe.nothing();
    },
  });
}

A couple additional things to notice here:

1. When we are in maybeWorkDone(), we have already handled the error, so there is no need to try/catch or to re-throw.

2. The use of .match() is good in this case because you want to console.error() on the error case, but only because of that logging. If you wanted to just switch to Maybe in that case, you could (a) do it in the original tryWork() instead or use import { toMaybe } from "true-myth/toolbelt";, which is the equivalent of Rust's Result::ok() method. (It's split out so you don't have to pay for the bundle size weight of both Maybe and Result if only using one of them in the browser.)

3. I dropped the async entirely from tryWork because I don't think it actually helps, as suggested above. Just using the callbacks is clearer! (As a bonus, I made it type safer: if you enable useUnknownInCatchVariables, what you had previously will throw! Notice that the API there is similar to the way nested errors work with libraries like Anyhow in Rust.)

4. The async on maybeWorkDone() is also optional; you could just as well write that like this:

   function maybeWorkDone2(): Promise<Maybe<string>> {
     return tryWork().then((result) =>
       result.match({
         Ok: (value) => Maybe.just(value),
         Err: (e) => {
           console.error("encountered error working", e);
           return Maybe.nothing();
         },
       })
     );
   }

Finally, if you want to handle this generically, you can write something like this:

function id<A>(a: A) {
  return a;
}

function asyncTryOrElse<T>(fn: () => Promise<T>): Promise<Result<T, unknown>>;
function asyncTryOrElse<T, E>(
  fn: () => Promise<T>,
  onErr: (value: unknown) => E
): Promise<Result<T, E>>;
function asyncTryOrElse<T, E>(
  fn: () => Promise<T>,
  onErr?: (value: unknown) => E
): Promise<Result<T, unknown>> {
  return fn().then(Result.ok<T, E>, onErr ?? id);
}

This does basically exactly what the more specific function you were working with does, but does it fully generically. Any Promise-producing function can be passed to this, and it will give you some flexibility by letting you transform the error but not requiring it.

(We might think about adding this to the library! It's high-utility and low-cost!)

Here's a TS playground demoing all of this!