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)
Per the September 2022 plenary discussion, we will continue to use
AggregateError, however we will make the results jagged such that eachAggregateErrorwill have at most one entry inerrorsand acausepointing back to any preceding error from disposal or the original completion.@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
.returnhas no idea if the closure is due to an error or not.