When `ReadableStream` read fails, stack trace does not include the line responsible

### Version 22.2.0 ### Platform ```text Microsoft Windows NT 10.0.22635.0 x64 ``` ### Subsystem _No response_ ### What steps will reproduce the bug? Save the following code to a file and run it: ```js import net from 'node:net' import stream from 'node:stream' const socket = net.connect(90, 'host.invalid.',) socket.on("error", e => { console.warn("socket error:", e.message) }) let myStream = stream.Duplex.toWeb(socket) console.log("next line throws") await myStream.readable.getReader().read() console.log("this line will never be reached") ``` ### How often does it reproduce? Is there a required condition? _No response_ ### What is the expected behavior? Why is that the expected behavior? From the output, you can see there was an error, but you can't see *why* that crashed the process. The output should mention the line number of the `read()` call so that the user can add necessary error handling. Note that `--async-stack-traces` does not make the output any more useful. ### What do you see instead? ``` console > node index.mjs next line throws socket error: getaddrinfo ENOTFOUND host.invalid. node:internal/modules/run_main:115 triggerUncaughtException( ^ Error: getaddrinfo ENOTFOUND host.invalid. at GetAddrInfoReqWrap.onlookupall [as oncomplete] (node:dns:120:26) { errno: -3008, code: 'ENOTFOUND', syscall: 'getaddrinfo', hostname: 'host.invalid.' } ``` ### Additional information A bad and easy to forget workaround is to wrap each `await` call. ```js await reader.read().catch(e => { throw new AggregateError([e]) }) ``` A better workaround might be possible with the (discouraged) [async hooks API](https://nodejs.org/api/async_hooks.html).