RFR JDK-8087113: Websocket API and implementation

[Pavel Rappo]

Hi Simone,

> On 4 Apr 2016, at 20:07, Simone Bordet <simone.bordet at gmail.com> wrote:
> 
> 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.

Am I right saying that you propose that all exceptions (incl. NullPointerException, 
IllegalArgumentException, etc.) to be relayed through the CompletionStage rather
than thrown in-place?

> 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.

You're right. I knew that well when decided to use it. Look through the JDK code
and you'll find that InternalError is used for cases like this very often. It's
a de facto standard.

Now, I'm not saying this is the right thing to do. But between finding my own
way and being consistent with the rest of JDK I chose latter.

As I understand there's no Throwable at the moment that is designed to allow a
programmer to indicate their assumptions/assertions don't hold. Sometimes people
(e.g. JUnit) use java.lang.AssertionError for this. But I don't think it's
correct either. This error was designed to be used by the language `assert`
construct. And throwing it from other contexts might give one a false impression
that assertions are on, when they are in fact off. Maybe this error shouldn't
have had public constructors. I don't know.

All in all it's a good question to ask on core-libs-dev list: which Throwable
should be assigned for cases like that?