Closed Rafat97 closed 1 year ago
This is definitely expected behavior--not an issue with the library--because you're not awaiting the rejected promise that's returned by the call to myEventErrorHandler
. As a result, there's no mechanism allowing the rejected promise to be handled.
In fact, you can see this same problem another way by replacing the line:
eventEmitter.emit("event:error", req, res);
with
myEventErrorHandler(); // NOT awaited, but see how the behavior changes when you do
With or without this library, you will still end up with the exact same error for the exact same reason--because you've allowed a rejected promise to sit unhandled until the end of the current iteration of the event loop. Only once you await
a rejected promise does it become an exception which can be handled higher up the call stack.
However, there's a second issue. If you stuck with me this far, you might think that the solution is just to await
the eventEmitter.emit(...)
line, right? Unfortunately, no. The emit
method of EventEmitters returns a boolean, not the return value of any listener function, meaning you can't await it. And that's for good reason. Not only can there be multiple listeners and thus multiple return values, but also because the purpose of an event-driven architecture is to separate the concerns of the publisher (i.e. the emitter) from the concerns of the subscriber(s) (i.e. the listener(s)). If there's an error in a listening function, that should be handled by the subscriber, not the publisher.
I created an express router. The main functionality of this router is to emit some events based on some of my business logic. Mainly, I tried to implement an event-driven architecture using
events.EventEmitter()
. My source code is-In the console, I get this error message.