$ loading_
帮助开发者排查 VS Code 遥测中的未处理错误并定位根因。
复制安装指令，让 AI 自动完成配置 · 推荐新手
请帮我安装 askskill 上的 "fix-errors" 技能： 1. 下载 https://raw.githubusercontent.com/microsoft/vscode/main/.github/skills/fix-errors/SKILL.md 2. 保存为 ~/.claude/skills/fix-errors/SKILL.md 3. 装好后重载技能，告诉我可以用了
请根据这条 VS Code 错误遥测信息分析根因：包含错误消息、堆栈跟踪、hit/user 数。请沿调用栈判断是哪一层产生了无效数据，哪一层只是消费该数据后崩溃，并给出建议修复点与理由。
一份根因分析，区分数据生产者与崩溃消费者，并指出优先修复位置。
下面的未处理错误消息信息不足，难以通过遥测定位问题。请改写为更适合诊断的错误消息，并说明应补充哪些上下文字段、状态信息或参数，以便后续在遥测面板中更快定位原因。
更清晰的错误消息示例，以及建议补充的诊断上下文清单。
请审查这段与报错相关的处理逻辑，重点检查是否存在 silently swallowing errors、过晚捕获异常、缺少上下文包装等反模式。结合遥测排查视角，给出更稳妥的错误处理与日志上报建议。
一份反模式审查结果，以及更利于遥测排查的改进方案。
When fixing an unhandled error from the telemetry dashboard, the issue typically contains an error message, a stack trace, hit count, and affected user count.
The error manifests at a specific line in the stack trace, but the fix almost never belongs there. Fixing at the crash site (e.g., adding a typeof guard in a revive() function, swallowing the error with a try/catch, or returning a fallback value) only masks the real problem. The invalid data still flows through the system and will cause failures elsewhere.
Read each frame in the stack trace from bottom to top. For each frame, understand:
The goal is to find the producer of invalid data, not the consumer that crashes on it.
Sometimes the stack trace only shows the receiving/consuming side (e.g., an IPC server handler). The sending side is in a different process and not in the stack. In this case:
Fix the producer directly:
UriComponents objects, not as strings)Given a stack trace like:
at _validateUri (uri.ts) ← validation throws
at new Uri (uri.ts) ← constructor
at URI.revive (uri.ts) ← revive assumes valid UriComponents
at SomeChannel.call (ipc.ts) ← IPC handler receives arg from another process
Wrong fix: Add a typeof guard in URI.revive to return undefined for non-object input. This silences the error but the caller still expects a valid URI and will fail later.
Right fix (when producer is unknown): Enrich the error at the IPC handler level and in _validateUri itself to include the actual invalid value, so telemetry reveals what data is being sent and from where. Example:
// In the IPC handler — validate before revive
function reviveUri(data: UriComponents | URI | undefined | null, context: string): URI {
if (data && typeof data !== 'object') {
throw new Error(`[Channel] Invalid URI data for '${context}': type=${typeof data}, value=${String(data).substring(0, 100)}`);
}
// ...
}
// In _validateUri — include the scheme value
throw new Error(`[UriError]: Scheme contains illegal characters. scheme:"${ret.scheme.substring(0, 50)}" (len:${ret.scheme.length})`);
Right fix (when producer is known): Fix the code that sends malformed data. For example, if an authentication provider passes a stringified URI instead of a UriComponents object to a logger creation call, fix that call site to pass the proper object.
Before proposing any fix, always find and read the code that constructs the error. Search the codebase for the error class name or a unique substring of the error message. The construction code reveals:
…
帮助开发者验证 Azure DevOps 流水线改动，快速排查构建与 YAML 配置问题。
沉淀并查询代码库经验教训，帮助开发、验证与评审减少重复踩坑。