On 4 Apr 2016, at 17:00, Simone Bordet <simone.bor...@gmail.com> wrote:
> Hi, > > On Mon, Apr 4, 2016 at 4:02 PM, Pavel Rappo <pavel.ra...@oracle.com> wrote: >> I see your point. Yes, working asynchronously kind of suggests that we should >> relay all exceptions through the asynchronous interface (CF in this >> particular >> case), simply because otherwise we would have to handle exceptions in many >> places (like you have illustrated). >> >> But there's a force working in the opposite direction. The further the thrown >> exception is from it's origin, the more of its context we loose. > > I don't know what you mean here. > >> In addition to this, some exceptions would clearly mean clear programmatic >> errors, that could easily be detected on the spot. E.g. passing null, or a >> negative value, where the positive or 0 is expected. Or a state problem. E.g. >> trying to send more data after a Close message has been already sent. The >> same >> with permits exhausting (let's now forget you're looking into the >> implementation >> rather than in the API). In the API only 1 incomplete/outstanding/queued >> write >> is permitted at any given time. It's a an application's fault if it doesn't >> keep >> an eye on whether or not the previous send has been completed. I can hardly >> imagine what could be done in the catch block above in this case. > > In my experience, it does not matter. > We went the way of throwing exceptions in case of API misuse by the > application, only to be bitten multiple times: "oh darn, an exception > has been thrown, that callback/CF was nested, did not get notified, > the whole system halted because of that missing notification via > callback/CF". > We reimplemented and never did it again, and lived happier since. > > You have designed an API that returns CFs, but then you also say "oh, > btw we don't notify the CF but we can throw exceptions". > That's a mixed design that is not friendly with users, no matter what > you think is an "application" error. > Application writers are now forced to wrap *every* single API call > with a try/catch because they don't know if you are going to notify > the CF or throw an exception. > Try to combine 2 CFs where one is from the WebSocket APIs. > Yuck! 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? -Chris.
