Hi, On Tue, May 10, 2016 at 2:03 PM, Pavel Rappo <pavel.ra...@oracle.com> wrote: > 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 guess the point is to answer the question of what semantic you want to have when calling a WebSocket method that returns a CF. CF wsCF = ws.sendBinary(...); wsCF.exceptionally(failure -> sendImportantEmail(failure)); Is an application required to implement both CF.exceptionally(fn) *and* surround ws.sendBinary() with a try/catch in *all* call sites ? My take is that because there are certain errors that cannot be detected early (or in the same thread) and therefore there must be a mechanism to report errors via the CF, then perhaps it would be best to only use that mechanism. By performing the sanity checks immediately, and notifying (synchronously) the CF rather than throwing, you would maintain the stack trace that led to the wrong call, so you would be able to look at the stack to know what was the call chain that passed, for example, a null ByteBuffer to sendBinary(...). Now, the question of the immediate sanity checks can be debatable and I don't have a strong opinion: I can live with it if you decide to throw. However, *any* exception that happen later in the processing, possibly after a thread dispatch, *must* be reported as a CF failure. You cannot let later IllegalStateExceptions or such to unwind the thread stack without notifying the CF. >> 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. In almost all the places where InternalError is thrown in the WebSocket implementation, you can throw an IllegalStateException or other runtime exceptions. Anyway, your call. -- 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
