- From: juner <notifications@github.com>
- Date: Thu, 29 Jan 2026 16:28:40 -0800
- To: whatwg/streams <streams@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/streams/issues/1359/3821110479@github.com>
juner left a comment (whatwg/streams#1359)
@ricea
That's certainly true...
> I agree that's it's annoying that `enqueue()`, `close()` and `error()` throw exceptions on closed streams, but I wouldn't call them "unsafe". Signalling that they have not worked can be useful to prevent code from malfunctioning. If `enqueue()` didn't throw it would be easy to accidentally write code that kept trying to enqueue to a closed stream forever.
One possible refinement I’ve been considering is to drop the “safe” framing entirely and instead make the stream’s completion state observable.
Concretely, something along these lines:
```js
const resolvers = ReadableStream.withResolvers();
const { stream, enqueue, close, error } = resolvers;
resolvers.completed;
// → true if close() or error() has already been called, otherwise false
```
Here, `completed` would be exposed as a getter rather than a plain boolean value. If it were a data property, destructuring would snapshot the value and wouldn’t reflect subsequent state changes, which seems error-prone. A getter allows producers to deliberately check the current completion state without changing any existing semantics.
This approach wouldn’t suppress exceptions from `enqueue()`, `close()`, or `error()`, nor would it alter backpressure behavior. Those operations would still fail fast as they do today. The goal is simply to provide an explicit, opt-in way for producers to observe completion and avoid late enqueues intentionally, rather than relying on try/catch.
Exposing dynamic internal state via getters is also consistent with existing Streams APIs such as `stream.locked` or `controller.desiredSize`, which makes this feel like a natural extension rather than a special case.
--
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/1359#issuecomment-3821110479
You are receiving this because you are subscribed to this thread.
Message ID: <whatwg/streams/issues/1359/3821110479@github.com>
Received on Friday, 30 January 2026 00:28:44 UTC