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.