Hi, On Mon, Apr 4, 2016 at 8:45 PM, Chris Hegarty <chris.hega...@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
