[Chris Hegarty]

Simon,

Only a partial reply, I’ll reply with other details later.

> On 15 May 2018, at 16:10, Simon Roberts <simon at dancingcloudservices.com> wrote:
> 
> If I understand you correctly, you are saying that the "simple" version of the code-code by the way that the project's main web page presents as it's first example--is so simple that it's actually unusable in any production scenario.

That is not what I am saying. What I am saying is that the String handler is a convenience handler that buffers all the response data and returns it once decoded. In some circumstances it is just not possible to return, as a String, the response data, if the server behaves incorrectly. In the scenario you are encountering it appears that the server is returning too little data. It may not be possible to always decode this partial data. And even if you do decode this partial data, something further up the stack is likely to fail, if parsing JSON for example.

My point is that if you want fault tolerance in the case of a misbehaving server there are other ways to achieve that.

> I know I cannot use code for production that fails to read any data from a (presumably) merely mis-configured server (a server from which all other tools successfully read data.

What do you hope to do with partial data read from the server? If it’s JSON can you decode it, or a gif can you display it?

> Did I interpret correctly, or did I miss something? If correctly, I'd be surprised if that doesn't strike you as sub-optimal to the point your pride in your work would want to make it more usable.

We do have pride in our work. I am engaging here to try to help you.

> It doesn't seem inappropriate to report a "warning" situation using an exception? Would not an aggregate return that includes data, headers, status code, ... and warnings be more helpful in this case?

There are other ways to achieve that, but IMO doing so for the String handler would not be helpful to the vast majority of Java developers, that would not check the carried warning.

> Mis-configured servers (assuming that's the cause) are not uncommon around the web.

Sure, but many clients will not be able to operate correctly with such, it’s a matter of where and how they fail.

> But perhaps more importantly, whatever the problem is, it is not fixed by your code. The error is actually thrown by the *send* call, as I've now determined as a result of trying your code. (I modified it very slightly so as to complete it, and catch the exception.)

D’oh! Apologies, that’s what I get for sending something without testing it more carefully, but you seem to have gotten past it.

-Chris