lib: callbacks firing twice if first attempt throws

[LiviaMedeiros]

There are a few places where code flows like this:

try {
  // some code that produces `result` and can potentially throw
  callback(null, result); // no error, return result
} catch(error) {
  callback(error);
}

These are usually (if not always) bugs, because it wraps the callback call itself in the try block, and if that callback throws, it gets caught and called again, but this time with its own error.

For example:

• node/lib/internal/fs/dir.js

  Lines 150 to 160 in 06fb007

  	try {
  	this.processReadResult(this.#path, result);
  	const dirent = ArrayPrototypeShift(this.#bufferedEntries);
  	if (this.#options.recursive && dirent.isDirectory()) {
  	this.readSyncRecursive(dirent);
  	}
  	callback(null, dirent);
  	} catch (error) {
  	callback(error);
  	}
  	};

  (going to be fixed in fs: prevent multiple invocations of callback in Dir class #58430)

• node/lib/internal/streams/compose.js

  Lines 153 to 161 in 06fb007

  	d._write = async function(chunk, encoding, callback) {
  	try {
  	await writer.ready;
  	writer.write(chunk).catch(() => {});
  	callback();
  	} catch (err) {
  	callback(err);
  	}
  	};

• fs: remove IIFE in glob #58418

Some of these bugs might be a good first issue Issues that are suitable for first-time contributors. candidates.

[bnoordhuis]

What happens with the exception when it's no longer caught but bubbles upwards instead? It's important that it doesn't just disappear into the void.

[0hmX]

@bnoordhuis I don't think the errors will go unnoticed. I shared a piece of code included in the patch: https://github.com/0hmX/node/blob/2fdc8ee07ff51c532162bc34614251cbcbd1ee43/lib/internal/fs/dir.js#L148-L158

We simply check if an error has already occurred; if so, we call the callback with the error; otherwise, we make a regular success callback.

[LiviaMedeiros]

What happens with the exception when it's no longer caught but bubbles upwards instead?

If an exception happens in the callback and is not caught inside the callback, it should bubble up and crash the program (unless something like process.on('uncaughtException') or even domain intercepts it), just like any other unhandled error.

[bnoordhuis]

I agree that's what should happen but it's important to check (not assume) it really happens.