Greg Wilkins

@stuartwdouglas I'm OK with that interpretation (that write should not throw), but then there are still some issues: - which onError should be called? (or both?) - what if a...

- I'm generally -0 for reporting an exception more than once. We should throw it, report it in WL.onError or report it in AL.onError, but not 2 of these and...

I know what you mean. It is ugly having 3 onError methods. But if a stream is reset whilst there are no IO operations, then is an exception delivered to...

So if I'm reading you both right.... in async mode: - mode, write, flush & close may throw an Exception either for the current operation they are called for or...

> IMHO write, flush and close should never throw, we should have one place to handle errors and that should be the listener. yeah but no!! There are two listeners...

This is from 3 days ago, but with the addition that write can throw if it is called after a previously reported exception. In async mode: - mode, write, flush...

Thanks @lachlan-roberts. I'll comment a bit here about what think should be the behaviour and then discuss it in more detail in the PR review. I see no problem with...

I think this is a good idea. Want to provide a PR?

Current Jetty implementation is: ```java // If we are not async and not closed already, then close via the possibly wrapped response. if (!baseRequest.getHttpChannelState().isAsync() && !baseResponse.getHttpOutput().isClosed()) { try { response.getOutputStream().close();...

Stuart, I'll review your text in detail shortly, but I do have an issue with: > * At the moment AsyncListener.onError is only really called as a result of dispatch...