diff --git a/dom.bs b/dom.bs index 5d7c0ce26..5e04fed6c 100644 --- a/dom.bs +++ b/dom.bs @@ -1667,7 +1667,7 @@ The API which wishes to support aborting can accept an {{AbortSignal}} object, a determine how to proceed.
APIs that rely upon {{AbortController}} are encouraged to respond to {{AbortController/abort()}} -by rejecting any unsettled promise with a new "{{AbortError!!exception}}" {{DOMException}}. +by rejecting any unsettled promise with the {{AbortSignal}}'s [=AbortSignal/abort reason=].
A hypothetical doAmazingness({ ... })
method could accept an {{AbortSignal}} object
@@ -1696,7 +1696,7 @@ controller.abort();
function doAmazingness({signal}) {
if (signal.aborted) {
- return Promise.reject(new DOMException('Aborted', 'AbortError'));
+ return Promise.reject(signal.reason);
}
return new Promise((resolve, reject) => {
@@ -1704,16 +1704,20 @@ function doAmazingness({signal}) {
// But also, watch for signals:
signal.addEventListener('abort', () => {
// Stop doing amazingness, and:
- reject(new DOMException('Aborted', 'AbortError'));
+ reject(signal.reason);
});
});
}
-
- APIs that require more granular control could extend both {{AbortController}} and - {{AbortSignal}} objects according to their needs.
APIs that do not return promises can either react in an equivalent manner or opt to not surface +the {{AbortSignal}}'s [=AbortSignal/abort reason=] at all. {{EventTarget/addEventListener()}} is an +example of an API where the latter made sense. + +
APIs that require more granular control could extend both {{AbortController}} and +{{AbortSignal}} objects according to their needs. +