`await using` hides potential unhandled promises.

[lukiano]

Bug Report

See explanation below the code.

🔎 Search Terms

await using disposable

🕗 Version & Regression Information

5.2 beta

💻 Code

(Symbol as any).dispose ??= Symbol("Symbol.dispose");
(Symbol as any).asyncDispose ??= Symbol("Symbol.asyncDispose");

import {promisify} from "util";
const delay = promisify(setTimeout);

class Resource {
  constructor(public readonly path: string) {}
  async [Symbol.asyncDispose]() {
    await delay(500);
    console.log('closed ' + this.path);
  }
}

class Boom extends Error {
  constructor() {
    super("Boom!");
  }
}

async function main() {
  await using file = await new Resource("thefile.txt");
  console.log(file.path);
  return Promise.reject(new Boom());
}

try {
  await main();
} catch (err) {
  console.log(`All good. Caught ${err.message}`);
}

🙁 Actual behavior

Boom [Error]: Boom!
    at main (file:///Users/luciano/git/ts-using/lib/index.mjs:70:31)
    at async file:///Users/luciano/git/ts-using/lib/index.mjs:83:5

The boom error is thrown due to being unhandled.

Explanation

My understanding is that this is happening due to return Promise.reject(new Boom()); returning a rejected promise, and the delay (with setTimeout) in the disposable function. The delay makes the rejected promise be seen and thrown.

It would be similar if the delay were in a finally section. However, the disposable function could be in an object within a library and thus not easily seen by users.

🙂 Expected behavior

thefile.txt
closed thefile.txt
All good. Caught Boom!

Caveat

The boom error should have been caught.

It could be that this isn't a bug, but working as expected. If so, let's consider making it clear in the documentation (e.g. use throw or return await Promise.reject()

[lukiano]

Thanks to @tnymlr, who made me curious to try this after explaining how it fails on a finally block.

[rbuckton]

@lukiano: What script target are you using? If I run this sample code in the playground I get your expected result: Playground

[rbuckton]

I will note that if you use return Promise.reject(new Boom()) and your disposer throws a different error, then the new Boom() error will be lost, while awaiting or just simply throwing the error will result in a SuppressedError containing both errors (or an Error analog if SuppressedError is not shimmed).

• Example where Boom is lost: Playground link
• Example where a SuppressedError analog is caught: Playground link

[lukiano]

This is my tsconfig.json

{
  "compilerOptions": {
    "outDir": "./lib",
    "target": "es2022",
    "lib": ["es2022", "esnext.disposable"],
    "module": "es2022",
    "moduleResolution": "node"
  },
  "include": ["./src"]
}

[lukiano]

And my package.json for completeness

{
  "scripts": {
    "compile": "tsc",
    "start": "node lib/index.mjs"
  },
  "devDependencies": {
    "typescript": "^5.2.0-beta",
    "@types/node": "^20.4.2"
  }
}

[lukiano]

There must be something different in the playground or Chrome's V8 w.r.t. unhandled rejections because

async function main() {
    const file = new Resource("thefile.txt");
    try {
      console.log(file.path);
      return Promise.reject(new Boom());
    } finally {
      await delay(500);
      console.log('closed ' + file.path);
    }
  }

isn't failing either.

[lukiano]

Actually, I'm seeing the unhandled rejection in the console window, but less than a second later it disappears.

[rbuckton]

Ah, I see what you are getting at. Yes, this is the expected behavior because the rejection isn't awaited. You would see the same thing happen if you just used try..finally:

async function f() {
  try {
    return Promise.reject(new Boom());
  } finally {
    await null;
  }
}

This will also result in an unhandled rejection because the return value is still "unhandled" when the await in the finally block suspends execution. It isn't adopted by the Promise for the async function until all finally blocks are evaluated, including the implicit one created by await using. It's generally a bad practice to return a Promise in an async function since any rejections won't be caught in the body.

[lukiano]

It's generally a bad practice to return a Promise in an async function

I agree. That said, coming back to my example:

async function main() {
  await using file = await new Resource("thefile.txt");
  console.log(file.path);
  return Promise.reject(new Boom());
}

For someone unfamiliar with using it's not apparent that there's an "implicit finally section". Hence my suggestion about documentation. I wonder what the tc39 group thinks about this.

[rbuckton]

I agree that this should be called out in documentation.