不能用 try-catch 全量拦截原生底层进程的异步抛错行为,因其无法跨进程、跨线程、跨语言捕获;需通过进程监控、标准流审计、IPC 错误封装、崩溃快照等分层机制实现全量可观测与审计。
不能用 try-catch 全量拦截原生底层进程的异步抛错行为。
桌面应用中调用的原生底层进程(如通过 Node.js 的 child_process 启动的独立可执行文件、C++ 插件、Rust 二进制模块、或系统级服务)属于独立操作系统进程,其异常发生在不同地址空间、不同运行时环境,甚至不同语言栈中。JavaScript/TypeScript 的 try-catch 仅作用于当前 JS 执行上下文中的同步或 await 等待的 Promise 异常,对以下情况完全无效:
error 或 exit)Result<T, E>,但 JS 层未做 unwrap() 或错误映射,就默认当作成功处理所谓“全量”,不是靠语法糖兜底,而是建立覆盖进程生命周期、通信通道、错误语义的可观测链路:
spawn 后的 error 事件(启动失败)、exit 事件(退出码 + signal)、close 事件(流关闭),记录 timestamp、pid、exitCode、signal、启动参数stderr 做实时文本匹配(如关键词 “panic:”, “Exception:”, “Segmentation fault”, “FATAL”),触发告警并截取上下文行;对 stdout 中约定的 JSON 错误格式(如 {"level":"error","msg":"..."})做结构化解析{ success: false, code: 'PROCESS_CRASH', detail: { pid: 1234, signal: 'SIGABRT' } }),禁止裸传字符串或静默丢弃CRASH_DUMP_DIR=/tmp/myapp-crash),配合原生层生成 core dump / minidump,并由主进程定期扫描上报它只能保护你写的那一小段 JS 胶水代码,前提是:原生调用已被封装为返回 Promise 的函数,且该 Promise 在底层出错时正确 reject。示例:
✅ 正确封装(暴露可捕获的 Promise)async function runNativeTool(args) { return new Promise((resolve, reject) => { const proc = spawn('mytool', args); proc.on('error', reject); // 启动失败 proc.on('exit', (code, signal) => { if (code !== 0 || signal) { reject(new Error(`Tool exited with code ${code}, signal ${signal}`)); } else { resolve(); } }); proc.stderr.on('data', (chunk) => { const str = chunk.toString(); if (/panic|FATAL/i.test(str)) { reject(new Error(`Native tool panic: ${str.slice(0, 200)}`)); } }); });}// 此处 try-catch 才真正有效try { await runNativeTool(['--validate', '/path']);} catch (e) { auditLog.error('Native tool failed', { error: e.message, traceId: currentTraceId });}
最终审计目标不是“不让错发生”,而是确保每个底层错误都能关联到:
这需要在各层主动注入 traceId、打点日志、结构化错误对象,而非依赖某一行 try-catch。