Re: [whatwg/streams] Proposal: `ReadableStream.withSafeResolvers()` (Issue #1359)

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