proposal-explicit-resource-management: Consider giving this a new type of error.

Currently I understand that failures in resource cleanup will be thrown as an AggregateError, which may or may not have a cause property depending on whether or not the block which uses the resources errored.

I would like to suggest that there be a ResourceDisposalError or some new type of error, because developers will sometimes want to handle cleanup errors. It may be that I use a particular resource for which I know it is possible for disposal to fail, and I know that I don’t care if it does. If so the current spec forces me to write:

try {
  await criticalActionUsingResources()
} catch(e) {
  // Did the critical action complete? Filter out disposal errors for separate handling
  if (e instanceof AggregateError) {
    // But I don't know if this is a resource cleanup error!
    // Maybe it's a failed Promise.all
  }
}

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 1
  • Comments: 20 (5 by maintainers)

Most upvoted comments

Per the September 2022 plenary discussion, we will continue to use AggregateError, however we will make the results jagged such that each AggregateError will have at most one entry in errors and a cause pointing back to any preceding error from disposal or the original completion.

I want to share a use case about error management. I am thinking about using it in the context of a SQL transaction in this way: […] (It implies Symbol.exitContext method needs to be called before Symbol.dispose method.)

I think the lack of error context could be problematic for this particular use case.

@nicolashenry I’d like to move any further discussion around error handling to #49, so I’ve copied your comment to that issue.

I’d like to not repeat the iterator close semantics which suppress closing errors, and make it impossible to report those. It can’t even be reported manually (e.g. unhandled rejection or explicit console.log) because the .return has no idea if the closure is due to an error or not.