-
Notifications
You must be signed in to change notification settings - Fork 8
Close output channel on error #42
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
Conversation
| (write-message writer msg) | ||
| (catch Throwable e | ||
| (async/close! messages) | ||
| (throw e))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose this throw is enough to the developer know this was a JSON parse exception or something right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it depends a bit on the setup. Because this runs within a core.async/thread, the exception is probably given to the thread's uncaught exception handler. I think the default one will dump the stack trace to stderr, but many logging frameworks will allow to install a custom handler to log those. Definitely something people should do.
As a library, I figured we should stay un-opinionated here and just throw.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, agreed
ericdallo
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
mainej
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like a practical solution. One suggestion below, but looks good!
|
Thank you! |
Fixes #41
This approach closes the output channel when writing a message to the output stream fails for any reason. Expected reasons are:
This will prevent the server from blocking forever on a channel that has no more consumers. Instead, messages will be dropped.
We expect that the client will send an exit message and eventually close the connection. This will close the server's input channel and allow it to terminate.