A get() that returns void is an odd beast indeed. If the get() is just to
verify the send, perhaps it could be renamed. Calling it a Future would be
odd, too, given that it doesn't follow the Future that people would expect.
On Sat, Feb 2, 2013 at 4:06 AM, Danny Coward <danny.coward_at_oracle.com>wrote:
> Hi folks,
>
> This one's obliquely related to (
> http://java.net/jira/browse/WEBSOCKET_SPEC-110), but also this has come
> up elsewhere.
>
> Currently we are using 3 classes for async sends:-
>
> Future<SendResult>
> SendResult get()
> SendResult get(timeout, unit)
> cancel()
> isDone()
> isCancelled()
>
> SendHander
> setResult(SendResult sr)
>
> SendResult
> getException()
> isOK()
>
> RemoteEndpoint
> Future<SendResult> sendXXXByFuture(message)
> void sendXXXByCompletion(message, SendHandler)
>
> For the information transmitted during the async operation ("did it get
> sent or not ?"), this is perhaps a little heavyweight. It also creates an
> ambiguity when using the Future<SendHandler> if the operation fails: does
> the exception get wrapped as the cause of the ExecutionException thrown on
> Future.get(), or is it set on the SendResult ?
>
> So here's a simpler alternative, which coveys the same information, but
> with less API and no ambiguity:-
>
> Future
> void get()
> void get(timeout, unit)
> cancel()
> isDone()
> isCancelled()
>
> SendHandler
> void handleSendError(Throwable t)
> void handleSendCompleted();
>
> RemoteEndpoint
> Future sendXXXByFuture(message)
> void sendXXXByCompletion(message, SendHandler)
>
> A send failure using the Future method results in the Throwable being
> wrapped as the cause of the ExecutionException thrown out of the
> Future.get() method, which is, after all, the proper use for that.
>
> I think its cleaner. Any other thoughts ?
>
> - Danny
> --
> <http://www.oracle.com> * Danny Coward *
> Java EE
> Oracle Corporation
>
--
You can find me on the net at:
http://antwerkz.com http://antwerkz.com/+
http://antwerkz.com/twitter http://antwerkz.com/github