VS Code FileSystem Provider扩展未知报错排查及实现合理性问询

你当前的实现存在几个明显的问题，是触发报错的高概率原因：

1. 冗余Promise包装导致错误上下文丢失：你在外层额外包装了一层new Promise，属于典型的Promise嵌套反模式，Connection.instance.send本身就返回Promise，直接返回该实例即可，多余的包装会干扰错误栈的生成，也会增加异常漏处理的概率。
2. 错误类型不符合VS Code预期：你在catch逻辑中统一把错误转成了普通Error实例，但VS Code的FileSystemProvider要求所有文件操作相关的异常必须抛出vscode.FileSystemError类型的实例，该实例内置uri属性，上层逻辑（包括VS Code内核、第三方扩展）访问error.uri时如果拿到的是普通Error，就会触发Cannot read property 'uri' of undefined的报错。
3. 无效同步异常捕获：你外层的try/catch只能捕获Connection.instance.send调用瞬间的同步错误，无法捕获send异步操作的异常，这部分代码完全无效。
4. 缺少边界判断：未判断reply是否为空的场景，如果WebSocket返回空响应，访问'error' in reply会直接触发异常。

改进后的实现参考 #

export class ScriptFS implements vscode.FileSystemProvider {
  // ...其他方法
  readFile (uri: vscode.Uri): Promise<Uint8Array> {
    // 直接返回异步操作的Promise，无需冗余包装
    return Connection.instance.send('scriptfs::read_file', { uri: uri.toString() })
      .then((reply: any) => {
        // 先判空，避免服务端返回空响应
        if (!reply) {
          throw vscode.FileSystemError.Unavailable('服务端返回空响应');
        }
        if ('error' in reply) {
          // 直接抛出VS Code内置FileSystemError，自带uri属性
          throw vscode.FileSystemError.FileNotFound(reply.error);
        }
        const enc = new TextEncoder();
        return enc.encode(reply.code);
      })
      .catch(err => {
        // 所有异常统一转成FileSystemError类型
        if (err instanceof vscode.FileSystemError) {
          throw err;
        }
        throw vscode.FileSystemError.Unavailable(err?.message || String(err));
      });
  }
  // ...其他方法也请按照相同逻辑修改错误处理
}

注意：所有Provider方法（stat、readDirectory、writeFile等）都需要按照上述逻辑修改错误处理，避免其他方法抛出普通Error触发相同问题。

• 开启TypeScript源码映射：在tsconfig.json中配置"sourceMap": true，确保编译后的JS代码和TS源码一一对应，调试时可以直接看到原始TS代码的调用栈，不会停在编译后的JS代码上。
• 添加全局异常监听：在扩展入口activate函数中添加全局监听逻辑，捕获所有未处理的异常：

  // 捕获全局未处理的同步错误
  window.addEventListener('error', (event) => {
    console.error('全局未捕获错误:', event.error, event.error?.stack);
  });
  // 捕获全局未处理的Promise拒绝
  process.on('unhandledRejection', (reason) => {
    console.error('未处理的Promise拒绝:', reason, (reason as Error)?.stack);
  });
  

• 开启调试异常暂停：在VS Code调试面板中勾选「Pause on Exceptions」，触发报错时调试器会直接停在抛错的位置，无需手动加日志即可查看完整调用栈。
• 排除第三方扩展干扰：你的报错前缀为Lintings failed on open，说明是lint类扩展触发的问题，可临时禁用所有非必要的第三方扩展，逐一测试定位是否是其他扩展不兼容自定义文件系统导致的报错。
• 开启VS Code详细日志：在扩展的launch.json配置中添加"trace": true，运行时可查看VS Code内核的完整调用日志，定位报错触发的具体环节。

内容的提问来源于stack exchange，提问作者Frank Blabu