-
-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Emitting the 'error' throws an unhandled error #15
Comments
Would you like to send a PR? |
leobudima
added a commit
to leobudima/mqemitter-redis
that referenced
this issue
Jan 15, 2020
leobudima
added a commit
to leobudima/mqemitter-redis
that referenced
this issue
Jan 15, 2020
Fixes issue with emitted error event names (mcollina#15)
mcollina
pushed a commit
that referenced
this issue
Feb 28, 2020
* Fix pipeline promises and handle errors Fixes #20 * Fixed lint * Fixed tests * Removed useless declaration * Use _onError instead of emit for errors * Bumped [email protected] * fix: _onError scope and ensure cb exists on close * fix: Unhandeld rejection when emit 'error' event * Bumped [email protected] and better close handler * revert connection error name, keep emitError * fix handle unhandled rejections #15 * emit error just when emitter is not closing
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In PR: #3 , the 'error' events are emitted using the EventEmitter - which, by default EE behavior, throws the error: https://nodejs.org/api/events.html.
In case of using mqemitter-redis indirectly, like in my case with multines, this cannot be caught, so it causes issues - for example, Redis disconnection, instead of automated reconnect, crashes Hapi.
If emitted events would be callled "pubError" and "subError" like in the original PR submission (or anything else, if more sensible), the issue would be solved.
The text was updated successfully, but these errors were encountered: