René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"util: `SuppressedError` should print `error`/`suppressed` properties during inspection","articleBody":"### What is the problem this feature will solve?\n\nWhen a `SuppressedError` is thrown (e.g. from disposal errors during a using/await using block) and inspected via `util.inspect()` / `console.log()`, then the actual underlying errors (`error` and `suppressed` properties) are not shown:\n\n```js\nclass Resource {\n  [Symbol.dispose]() {\n    throw new Error('error during dispose');\n  }\n}\nfunction test() {\n  using res = new Resource();\n  throw new Error('error during execution');\n}\ntest();\n```\nCurrent output (Node v26.8.2):\n```\nSuppressedError: An error was suppressed during disposal.\n    at test (REPL10:3:3)\n```\n\nBoth those errors are essential for debugging.\n\nThis has the exact same shape as two problems Node already solved for other \"container\" errors:\n\nAggregateError.errors was silently swallowed during inspection — fixed in #43646 (tracked in #43645).\nError.cause was silently swallowed during inspection — fixed in #41002 (tracked in #40859).\n\nSuppressedError.error / SuppressedError.suppressed fall into the same category and currently have no equivalent handling in formatError() (lib/internal/util/inspect.js).\n\n### What is the feature you are proposing to solve the problem?\n\nExtend `formatError()` so that, similar to how `cause` and `errors` are already special-cased, the non-enumerable error and suppressed properties of a SuppressedError are always included in the inspected output (recursively, since a SuppressedError can itself wrap another SuppressedError when multiple disposals fail).\n\nDesired output, roughly matching what the cause-chain rendering already does:\n```\nSuppressedError: An error was suppressed during disposal.\n    at test (…)\n    ... {\n  [error]: Error: error during dispose\n      at Resource.[Symbol.dispose] (…)\n      ...,\n  [suppressed]: Error: error during execution\n      at test (…)\n      ...\n}\n```\n\n### What alternatives have you considered?\n\n* Manually logging e.error and e.suppressed in application code — works, but requires every catch block to know it might be dealing with a SuppressedError.\n* A userland [util.inspect.custom] patch on SuppressedError.prototype — works.\n\nI believe a better out-of-the-box experience is required, rather than user-land patches. Workarounds shouldn't be necessary for a built-in error type tied to a TC39-standardized language feature","author":{"url":"https://github.com/zuozp8","@type":"Person","name":"zuozp8"},"datePublished":"2026-09-15T12:15:41Z","url":"https://github.com/nodejs/node/issues/66033"}