-
Notifications
You must be signed in to change notification settings - Fork 1.1k
GH-10314: Revise TcpListener.onMessage()
contract for void
#10315
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
…r `void` Fixes: spring-projects#10314 Looks like a `boolean` return for the `TcpListener.onMessage()` is a leftover of some earlier design or some idea which didn't make it into the project. On the other hand, all the logic in the project around this `onMessage()` usage is properly handled by the delegation or exceptions. * Change `TcpListener.onMessage()` to have a `void` as return type * Fix all the respective usages and simplify some implementations with removing those bogus `return false;` and using proper `if..else` logic if necessary * Fix some code style in the affected classes, like proper `assertThat` or diamond operators
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.
LGTM!
Just a couple of formatting nitpicks.
*/ | ||
@Nullable Message<?> getReply() { | ||
@Nullable | ||
Message<?> getReply() { |
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.
Why is the @Nullable
move to the line above the method?
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.
Because this method does not have modifiers and annotation is treated by formatter as for the whole method.
I agree on consistency discrepancy here, but I prefer to keep formatter happy to avoid unnecessary changes in the future .
this.interceptedSenders.forEach(snder -> snder.removeDeadConnection(connection)); | ||
if (sender != null && this.interceptedSenders != null | ||
&& !(sender instanceof TcpConnectionInterceptorSupport)) { | ||
|
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.
Blank line can probably be removed.
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.
Well, my preference for better readability is to have a blank line after multi-line if
.
Same reason as with a blank line before method body after multi-line header.
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 agree with your response.
Things look great!
Fixes: #10314
Looks like a
boolean
return for theTcpListener.onMessage()
is a leftover of some earlier design or some idea which didn't make it into the project. On the other hand, all the logic in the project around thisonMessage()
usage is properly handled by the delegation or exceptions.TcpListener.onMessage()
to have avoid
as return typereturn false;
and using properif..else
logic if necessaryassertThat
or diamond operators