Hi Simone, > On 4 Apr 2016, at 20:07, Simone Bordet <simone.bor...@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?
