Synchronous errors in async event handlers get caught too late

[peza]

Version

20.13.1, probably all others too.

Platform

All

Subsystem

No response

What steps will reproduce the bug?

When an async function throws an error during an event emitter callback, the error is not caught by catch block at the time of execution its event but only after all events are done. This behavior:

1. Violates developer expectations
2. Makes error handling in event emitters unreliable

Reproduction:

const EventEmitter = require('events');

// Simulate problematic Event emitter (opcua subscription messages, mqtt subscription messages, ...)
class SomeFunctionClass extends EventEmitter {
    async setValues(payload) {
        try {
            console.log(`Processing value: ${payload}`);


           // do some async db writes or opcuaServer.engine.addressSpace.write here


            throw new Error('The showcase Exception');
        } catch (e) {
            console.error(e);
            throw e;
        }
    }
}

function startClient() {
    const someFunctionClass = new SomeFunctionClass();
    return new Promise((resolve) => {
        // Using EventEmitter to simulate MQTT client
        const client = new EventEmitter();

        // Simulate connection
        setTimeout(() => {
            client.emit('connect');
            client.subscribe = (callback) => callback(null);
            resolve(client);
        }, 100);

        // Your exact message handler with the bug
        client.on("message", async (message) => {
            try {
                console.log(`Received message ${message}`);

                try {
                    await someFunctionClass.setValues(message);
                    console.log(`Message: ${message}`);
                } catch (e) {
                    console.error(`Error on setting value! FAR TOO LATE!!!!`, e);
                }
            } catch (err) {
                console.error(`Error processing message. Never comming here, which is OK`, err);
            }
        });
    });
}

// Test the implementation
(async () => {
    const client = await startClient();
    client.emit('message', 'Message1');
    client.emit('message', 'Message2');
})();

How often does it reproduce? Is there a required condition?

Always. No special Condition.

What is the expected behavior? Why is that the expected behavior?

All errors thrown in async functions called from event handlers should be catchable by surrounding try/catch blocks at the time of the function call.

What do you see instead?

All function calls first get executed and only then all the catch blocks get executed. (Immagine what would happen with some complex Error Handling)

Additional information

Impact: This affects all event emitter usage with async handlers (MQTT clients, OPCUA subscriptions,...)

Maybe this is technically correct per the spec, but creates dangerous real-world behavior, if one wants to handle all exceptions in an ExceptionHandler outside from the called async function.

[bnoordhuis]

I think you're confusing concepts although your description isn't clear enough that I can pinpoint it exactly. Event emitters are synchronous, async functions are not. If you mix them without being mindful of that, then yes, it's going to sting.

Not a bug though. I'm going to convert this to a discussion.

[peza]

Hello,

Thank you for your response. While I understand this behavior may be technically correct per the specification, I believe it creates significant real-world hazards that deserve reconsideration. Let me clarify the core concern:

The Practical Problem
Unintuitive Behavior:
When developers write try/catch blocks around async functions, they reasonably expect all errors to be caught - whether synchronous or asynchronous. The current behavior violates this fundamental expectation.

Event Processing Safety:
In message processing systems (MQTT, OPC UA, etc.), we need atomic error handling per message. A synchronous validation error should fail the current message processing immediately, not escape to become an unhandled rejection that might crash the entire process.

Debugging Nightmares:
The stack traces become disconnected from the original message context when errors escape to unhandledRejection, making production issues much harder to diagnose.

If the function exception is thrown per cause of wrong parameter value, the function itself should not handle it gracefully, but instead alert the caller with an Exception. And not 'Late in the process' but at the time of the message transaction.

I understand that this is usualy hadled with somesort of nasty workarounds using queues and additional messaging (error or not), but for me its a workaround and not nice coding.

This isn't just about theoretical purity - it's about preventing real-world system crashes in message processing pipelines. Even if the current behavior is technically "correct", the practical consequences suggest the spec may need revisiting for async/await contexts.

Would appreciate reconsideration of this as a potential enhancement if not a bug. The current behavior forces developers to choose between:

• Writing unsafe code that may crash
• Implementing verbose workarounds
• Avoiding async/await entirely in event handlers

None of these are good outcomes for the ecosystem.

[Kamakhya-s]

Event emitters are synchronous, meaning calling emit twice fires both listeners instantly before any await finishes.

To fix it, process events sequentially using an async loop or custom emitter that awaits each listener instead of using fire-and-forget emit().

[k4hvecii]

I think the behavior here is expected once the listener is an async function.

EventEmitter.emit() does invoke listeners synchronously, but it does not await their return values. emit() itself only returns a boolean indicating whether the event had listeners.

The important part is that an async function always returns a Promise. A throw inside an async listener therefore becomes a rejection of that Promise, even if the throw happens before the first await.

So conceptually:

async function listener() {
throw new Error("boom");
}

does not expose "boom" as a synchronous exception to the caller of listener(). It gives the caller a rejected Promise.

That means a try/catch surrounding:

emitter.emit("message");

cannot catch that rejection, because emit() does not return or await the Promise returned by the listener.

captureRejections is specifically designed to bridge this gap. Node attaches a rejection handler to Promises returned by listeners and routes rejected Promises to Symbol.for("nodejs.rejection") or the "error" event. That necessarily happens through Promise rejection handling, so it cannot behave like a synchronous throw from emit().

If the caller needs to wait for every handler and directly observe their errors, EventEmitter may not be the right abstraction for that particular operation. An explicit async dispatch method could make that contract clearer, for example by collecting the listeners' return values and awaiting them.

Something conceptually like:

async function emitAsync(emitter, event, ...args) {
await Promise.all(
emitter.listeners(event).map(listener => listener(...args))
);
}

Then:

try {
await emitAsync(emitter, "message", message);
} catch (err) {
// handler failure is observable here
}

For normal fire-and-forget events, captureRejections seems like the appropriate mechanism.

For events where completion and error propagation are part of the API contract, I would use an explicitly asynchronous API instead of expecting EventEmitter.emit() to propagate Promise rejections synchronously.

So I don't think Node can synchronously catch the initial throw from an async listener without changing the semantics of async functions or the EventEmitter API itself.