Oh, come on, there are more important issues to fix in HttpClient than
debating this. Look at the program below and tell me what the output is.
It behaves just like the current implementation of
RequestOutputStream.print(). I for one would be rather surprized if a print
method behaved any other way.
public class Fubar
{
public static void main(String args[])
{
System.out.println("Printing a null value: " + null);
}
}
Marc Saegesser
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 18, 2002 5:54 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [httpclient] revised patches: ResponseInputStream.java,
> Reque stOutputStream.java
>
>
> On Sun, 17 February 2002, "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?
>
> Yes, doesn't look pretty, looks hacky to me.
>
> > 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.
>
> Isn't this bad coding practice that also affects the code efficiency?
>
> Otis
>
> _________________________________________________________________
> iVillage.com: Solutions for Your Life
> Check out the most exciting women's community on the Web
> http://www.ivillage.com
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
