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. +

Interface {{AbortController}}