В результате ручного сброса ReadableStream или TransformStream ошибка регистрируется как необработанная ошибка

Question

При вызове ReadableStreamDefaultController.error или TransformStreamDefaultController.error с объектом Error для ручного вывода ошибки из потока ошибка регистрируется в консоли браузера на сайте вызова как необработанная ошибка, как если сам метод .error() повторно выдавал ошибку, которую он выдал.

Следующий короткий фрагмент с источником ReadableStream и назначением WritableStream демонстрирует проблему, однако, похоже, что консоли фрагмента stackoverflow не удается зарегистрировать ошибка (проверьте консоль браузера, на Chrome 80):

let sourceController;
let source = new ReadableStream({
    start: (controller) => {
        sourceController = controller;
    }
});

let destination = new WritableStream({
    start: () => {
    	// ...
    },
    abort: (reason) => {
    	console.log("aborted:");
        console.log(reason);
    }
});

source.pipeTo(destination);
window.setTimeout(() => sourceController.error(new Error("wut?")), 1000);
//                                       ^^^^^
//                                       js:30 Uncaught (in promise) Error: wut?

Судя по сообщению об ошибке, это может быть где-то отклоненное обещание, но я понятия не имею, где. Как ни странно, попытка наблюдать эту необработанную ошибку с использованием следующего слушателя также не имеет никакого эффекта:

window.onerror = (e) => console.error(e); // Never gets called

Я бы подумал, что определение метода abort для целевого объекта WritableStream отмечает, что поток включен с обработкой ошибок Тем не менее, ошибка по-прежнему записывается как неперехваченная ошибка (как ни странно, метод abort вызывается одновременно).

Мне кажется, что эта ошибка совершенно безвредна, но это, конечно, раздражает.

Как мне от этого избавиться? Добавление try ... catch вокруг вещи ничего не делает.

Answer 1

Ошибка возникает из-за обещания, возвращенного вызовом pipeTo, так как при сбое потока отклонит это обещание. Решение состоит в том, чтобы добавить отсутствующее предложение catch:

source.pipeTo(destination).catch(err => ...)

Или, в контексте выполнения async:

try {
    await source.pipeTo(destination);
} catch (err) {
    ...
}

Это объясняется в спецификации WHATWG Streams spe c:

Ошибка в исходном читаемом потоке приведет к прерыванию целевого доступного для записи потока, если в качестве метода предиката - верно. Возвращенное обещание будет отклонено с ошибкой источника или с любой ошибкой, возникшей при отмене пункта назначения.