RE: [httpclient] revised patches: ResponseInputStream.java, Reque stOutputStream.java

["Waldhoff, Rodney" <rw...@us.britannica.com>]

> AFAIK, the change to print would've broken 
> existing code compatibility.

True, although the current behavior:
  if(s == null) s = "null";
is a bit quirky, don't you think?

I'd be in favor of not allowing null, but just let the s.length() call throw
the NullPointerException rather than explictly checking for null on each and
every call.  When a one arg method throws NPE, it's pretty easy to figure
out what's null.

Re: [httpclient] revised patches: ResponseInputStream.java, Reque stOutputStream.java

[dIon Gillard <di...@multitask.com.au>]

Waldhoff, Rodney wrote:

>>AFAIK, the change to print would've broken 
>>existing code compatibility.
>>
>
>True, although the current behavior:
>  if(s == null) s = "null";
>is a bit quirky, don't you think?
>
Yep, but it matches what System.out.println and string concatenation do, 
so in that respect it's vaguely consistent.

>I'd be in favor of not allowing null, but just let the s.length() call throw
>the NullPointerException rather than explictly checking for null on each and
>every call.  When a one arg method throws NPE, it's pretty easy to figure
>out what's null.
>
So, keep or change?
--
dIon


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>