RFR JDK-8087113: Websocket API and implementation

[Simone Bordet]

Hi,

On Mon, Apr 4, 2016 at 8:45 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> Isn’t this the same as the new HTTP Client in java.net.http, e.g.
> HttpRequest::responseAsync ?  Do you think that this should be
> changed also?

I have not looked at the new HTTP client yet, but I will.

In my experience, having one single mean of notifying failures is the
best way to go.

The problems we had by not doing so were related to combining CFs
and/or forgetting to catch exceptions from our own APIs.
I imagine the new HTTP client could be used to re-implement
URLConnection and many other places where HTTP was used.
You can see those as "applications" within the JDK, but imagine the
try/catch boilerplate around the API calls.

Thin layers on top of the APIs (think ReactiveStreams) would need to
remember to try/catch every single API calls to avoid to fail the
upper layer.
For example, in ReactiveStreams you may call onNext() and then
decrease the demand. If onNext() throws the demand remains unchanged
and it can cause problems later.

In my experience, once you get rid of exception throwing in async API
everything becomes much simpler, especially "deep" exceptions related
to invalid implementation internal states.

I see that the WebSocket implementation throws InternalError.
This is typically used for *JVM* failures, not application failures.

Applications are used to catch Exception, not Throwable, so
InternalError may not be handled well.
I suggest to not use Error or subclasses for application or
implementation failures, but Exception or subclasses instead.

-- 
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz