Skip to content
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

error event for error handling #61

Open
AuHau opened this issue Aug 28, 2020 · 4 comments
Open

error event for error handling #61

AuHau opened this issue Aug 28, 2020 · 4 comments

Comments

@AuHau
Copy link

AuHau commented Aug 28, 2020

Currently, when you call emit() you can attache .catch() to the returned Promise for error handling. It has a limitation coming from Promise side as Promise can be only once resolved or rejected. But you can have multiple listeners for the event and if multiple listneres errors out then you will be notified only about the first one.

I would like to propose to have defined event name (error seems like good name and follows also similar event in the Node's EventEmitter) which would be called upon listener's error throw or rejection with the object passed with structure:

{
   event: string // name of the event of the listener that throw the error
   error: Error object
}
@sindresorhus
Copy link
Owner

What would the behavior be? Would it both reject on emit() and also emit an error event?

@AuHau
Copy link
Author

AuHau commented Sep 4, 2020

Good question! I am not so sure myself, any suggestion?

I am leaning towards having both and leave it up to the user to choose what he needs base on his usecase...

@sindresorhus
Copy link
Owner

I think it would be weird to do both. Then the user would have to both listen to an error event and also try/catch the .emit(). I'm not really happy about the current situation or the proposed one, so I'm going to keep this open for a while, hoping that someone will propose a better solution.


If we would go for an error event, it should be a Symbol to not conflict with user events: emitter.on(Emittery.error, …).

@AuHau
Copy link
Author

AuHau commented Sep 7, 2020

Ok. Well for having both, I did not really mean it as he would have to use both, but as he could choose based on his use-case (eq. if he has only one listener, than he can try/catch and if he would have multiple listeners then he can listen on the error event).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants