util: `SuppressedError` should print `error`/`suppressed` properties during inspection
まだ誰も着手していません。
- 主要言語
- JavaScript
- スター
- 122k
- フォーク
- 37.3k
- 平均マージ
- 4日 2時間
- マージ済み PR(30日)
- 283
説明
What is the problem this feature will solve?
When 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:
class Resource {
[Symbol.dispose]() {
throw new Error('error during dispose');
}
}
function test() {
using res = new Resource();
throw new Error('error during execution');
}
test();
Current output (Node v26.8.2):
SuppressedError: An error was suppressed during disposal.
at test (REPL10:3:3)
Both those errors are essential for debugging.
This has the exact same shape as two problems Node already solved for other "container" errors:
AggregateError.errors was silently swallowed during inspection — fixed in #43646 (tracked in #43645).
Error.cause was silently swallowed during inspection — fixed in #41002 (tracked in #40859).
SuppressedError.error / SuppressedError.suppressed fall into the same category and currently have no equivalent handling in formatError() (lib/internal/util/inspect.js).
What is the feature you are proposing to solve the problem?
Extend 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).
Desired output, roughly matching what the cause-chain rendering already does:
SuppressedError: An error was suppressed during disposal.
at test (…)
... {
[error]: Error: error during dispose
at Resource.[Symbol.dispose] (…)
...,
[suppressed]: Error: error during execution
at test (…)
...
}
What alternatives have you considered?
- 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.
- A userland [util.inspect.custom] patch on SuppressedError.prototype — works.
I 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
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
lib/internal/util/inspect.js の formatError() から始め、cause と errors に対する既存の特別な処理を比較します。SuppressedError.error と SuppressedError.suppressed が再帰的に表示されるように検査を拡張し、その後、util.inspect() と console.log() が破棄エラーに対して要求されたネストされた出力を生成することを確認します。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- javascript
- 領域
- tooling
- issue の種類
- 機能追加
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 活発さ
- 活発
- 明瞭さ
- 明確に書かれている
- 初心者へのやさしさ
- 78/100