Node.js v18.19.1中EBUSY异常绕过try/catch块原因咨询

环境：Windows 10系统，Node.js v18.19.1

实际代码 #

function moveFile(filePath, targetPath) {
    try {
        if (fs.existsSync(targetPath)) {
            return (0, core_1.fix)({ kind: 'target-file-exists' });
        }
    }
    catch (e) {
        console.log(`Unable to check if the target ${targetPath} for the source ${filePath} already exists. Unexpected error.`);
        console.log(e);
        return (0, core_1.fix)({ kind: 'unexpected-error', e });
    }
    try {
        fs.renameSync(filePath, targetPath);
        const stats = fs.statSync(targetPath, {});
        return (0, core_1.fix)({ kind: 'moved', size: stats.size });
    }
    catch (e) {
        if (e.code === 'ENOSPC') {
            return (0, core_1.fix)({ kind: 'no-space-left' });
        }
        else {
            console.log(`Unable to move ${filePath} to ${targetPath}. Unexpected error.`);
            console.log(e);
            return (0, core_1.fix)({ kind: 'unexpected-error', e });
        }
    }
}

程序崩溃输出 #

Error: EBUSY: resource busy or locked, rename 'v:/...' -> 'v:/...'
    at Object.renameSync (node:fs:1035:3)
    at moveFile (C:\mine\saving\built\server\disking.js:77:12)
    at moveSnap (C:\mine\saving\built\server\moving-files.js:165:42)
    at willBeMovingFiles (C:\mine\saving\built\server\moving-files.js:62:32)
    at async run (C:\mine\saving\built\server\start-moving-files.js:59:5) {
  errno: -4082,
  syscall: 'rename',
  code: 'EBUSY',
  path: 'v:/...',
  dest: 'v:/...'
}
Thrown at:
    at renameSync (node:fs:1035:3)
    at moveFile (C:\mine\saving\built\server\disking.js:77:12)
    at moveSnap (C:\mine\saving\built\server\moving-files.js:165:42)
    at willBeMovingFiles (C:\mine\saving\built\server\moving-files.js:62:32)


Node.js v18.19.1

疑问：为何该EBUSY异常未被try/catch块捕获，直接导致程序崩溃？

原因分析与解决 #

从代码和崩溃日志来看，fs.renameSync抛出的EBUSY理论上应该被第二个try/catch块捕获，但实际程序崩溃，大概率是以下几种情况：

1. core_1.fix函数抛出了新异常 #

当catch块捕获到EBUSY后，会执行else分支的console.log，然后调用core_1.fix({ kind: 'unexpected-error', e })。如果这个core_1.fix函数内部存在逻辑错误，或者它本身会抛出异常，那么这个新的异常会跳出当前catch块，向上传播。如果上层代码没有处理这个异常，就会导致程序崩溃。

你可以先检查崩溃前是否打印了Unable to move ... Unexpected error.这条日志：

• 如果日志打印了，说明EBUSY已经被捕获，崩溃是core_1.fix调用导致的，需要排查这个函数的实现。
• 如果日志没打印，说明异常根本没进入catch块，这种情况极少见，可能是Node.js版本的bug（可以尝试升级Node.js），或者文件系统存在特殊锁机制。

2. 上层调用未处理同步异常 #

从崩溃栈可以看到，moveFile是被异步函数run间接调用的。虽然moveFile是同步函数，但如果上层的异步函数（比如willBeMovingFiles或moveSnap）没有用try/catch包裹moveFile的调用，那么moveFile中抛出的任何异常（包括core_1.fix抛出的）都会被转化为rejected promise。如果你的程序没有监听unhandledRejection事件，Node.js就会直接终止程序。

3. 排查建议 #

• 在调用moveFile的上层函数（比如moveSnap）中添加try/catch块，兜底捕获所有异常。
• 暂时注释掉core_1.fix的调用，替换成简单的return语句，看程序是否还会崩溃，以此确认是否是该函数的问题。
• 给程序添加全局异常监听：

  process.on('uncaughtException', (err) => {
    console.error('未捕获的同步异常:', err);
  });
  process.on('unhandledRejection', (reason, promise) => {
    console.error('未处理的Promise拒绝:', reason, promise);
  });
  

  这样可以更清晰地定位异常来源。

内容的提问来源于stack exchange，提问作者Trident D'Gao