I couldn't disagree more!
// HERE IS PROBLEM!!! What should i do to correctly say to Spring - no message exist, continue work without Exceptions
Using an exception to convey information to something further down the stack is entirely legitimate.
Otherwise, you'd have to pass and test some 'special' return value (such as null) in *every* stack frame on the way down. In this case, the exception tells the framework that the socket was closed in an orderly fashion, and we can clean up properly. The intervening frames don't care about the condition.
We don't incur any additional overhead because we have to catch IOExceptions anyway (SEOSE is a subclass of IOException).
You don't need to worry about it being logged; we consume the exception at the appropriate stack frame; it is not logged; as I said it is used to convey information. Aside from not having to worry about the condition in all the stack frames between convert() in the connection and the low-level code in the deserializer; I feel it conveys more semantic value than, say, returning something like null or some other special value.
It is clearly documented in the javadoc for the exception as well as in the javadoc for the deserialize() method in our serializers.
If you used our serializer as a base, I don't see why you didn't use that part of the code.
You can disagree if you like, but if you want to avoid the 'can't send null' message, you need to throw the exception if the socket is closed before any part of a message is received.
Gary P. Russell
Spring Integration Team
SpringSource, a division of VMware