You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Sean C. Sullivan" <se...@seansullivan.com> on 2002/02/10 04:32:05 UTC
[httpclient] question regarding NameValuePair constructor, null parameters
Jakarta-commons HttpClient inquiry:
Why does the NameValuePair constructor allow
null parameters?
This is how the code currently looks:
NameValuePair.java
--------------------------
/**
* Constructor.
*/
public NameValuePair(String name, String value) {
this.name = name;
this.value = value;
}
--------------------------
With this constructor, it is allowable for a caller to do this:
NameValuePair nvp = new NameValuePair(null, null);
I would prefer if the NameValuePair constructor did not allow null parameters.
I prefer this constructor:
/**
* Constructor.
*/
public NameValuePair(String name, String value) {
if (null == name) {
throw new NullPointerException("name parameter is null");
}
if (null == value) {
throw new NullPointerException("value parameter is null");
}
this.name = name;
this.value = value;
}
Regards,
-Sean
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [httpclient] patch for GetMethod.java, recycle() method in GetMethod class
Posted by dIon Gillard <di...@multitask.com.au>.
Sean C. Sullivan wrote:
> jakarta-commons httpclient inquiry + patch:
>
>The HttpMethod interface declares a method called
>recycle():
>
>----------------
>
> /**
> * Recycle this method so that it can be used again.
> * Note that all of my instance variables will be reset
> * once this method has been called.
> */
> public void recycle();
>
>----------------
>
>The GetMethod class implements the HttpMethod interface
>and the recycle method:
>
>#################
>
> // override recycle to reset redirects default
> public void recycle() {
> super.recycle();
> setFollowRedirects(true);
> }
>
>################
>
>
>GetMethod.recycle() does not reset its instance variables properly.
>
>I am attaching a patch for GetMethod.java (patch file: GetMethod.patch)
>
>Cheers,
>
>-Sean
>
Applied....
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[httpclient] patch for GetMethod.java, recycle() method in GetMethod class
Posted by "Sean C. Sullivan" <se...@seansullivan.com>.
jakarta-commons httpclient inquiry + patch:
The HttpMethod interface declares a method called
recycle():
----------------
/**
* Recycle this method so that it can be used again.
* Note that all of my instance variables will be reset
* once this method has been called.
*/
public void recycle();
----------------
The GetMethod class implements the HttpMethod interface
and the recycle method:
#################
// override recycle to reset redirects default
public void recycle() {
super.recycle();
setFollowRedirects(true);
}
################
GetMethod.recycle() does not reset its instance variables properly.
I am attaching a patch for GetMethod.java (patch file: GetMethod.patch)
Cheers,
-Sean
Re: [httpclient] question regarding HttpMethod interface: getResponseBody method
Posted by dIon Gillard <di...@multitask.com.au>.
Sean C. Sullivan wrote:
>From: "dIon Gillard" <di...@multitask.com.au>
>
>
>>Sean C. Sullivan wrote:
>>
>>>Currently, HttpMethod.java (an interface) defines a
>>>method called "getResponseBody":
>>>
>>> /**
>>> * Return my response body, if any,
>>> * as a byte array.
>>> * Otherwise return <tt>null</tt>.
>>> */
>>> public byte[] getResponseBody();
>>>
>>>
>>>I would prefer if this method returns a zero-length array instead
>>>of null.
>>>
>>>Returning a zero-length array is one of the API design tips that
>>>is recommended in Josh Bloch's book:
>>>
>>> Effective Java Programming Language Guide
>>> http://www.amazon.com/exec/obidos/ASIN/0201310058/
>>>
>>>
>>>==> Item 27: Return zero-length arrays, not nulls
>>>
>>given I don't have the book handy, this doesn't make for a very
>>convincing argument as to why we should change the API. [...]
>>
>>Can you please provide some more info on why you'd like the change?
>>
>
>First, I want the behavior of getResponseBody to be consistent with
>the behavior of other "standard" (java.*) classes.
>
>Example 1: java.util.Vector.toArray
>
> The return value, Object[], will never be null.
>
>Example 2: java.lang.String.getBytes
>
> The return value, byte[], will never be null.
>
>In Josh Bloch's book, "Effective Java Programming Language Guide",
>Item 27 states:
>
> Return zero-length arrays, not nulls
>
>Rationale:
>
>If the method sometimes returns null and other times returns a non-null array,
>the programmer is forced to always check for null.
>
>With the current HttpMethod interface, programmers must write:
>
> byte[] result = hm.getResponseBody();
> if (result != null)
> {
> processBody(result);
> }
>
>If we return a zero-length array instead of null, programmers can write:
>
> byte[] result = hm.getResponseBody();
> processBody(result);
>
>>As well, the current api documents returning null. Which is cheaper from the
>>
>JVM
>
>>perspective than creating a new byte array.
>>
>
>Bloch (page 134) writes:
>
> "It is sometimes argued that a null return value is preferable to a
>zero-length
> array because it avoids the expense of allocating the array. This argument
>fails
> on two counts. First, it is inadvisable to worry about performance at this
>level
> unless profiling has shown that the method in question is a real contributor
>to
> performance problems. Second, it is possible to return the same zero-length
> array from every invocation that returns no items because zero-length arrays
> are immutable and immutable objects may be shared freely."
>
>Solution: declare a static zero-length array variable
>
> private final static byte[] ZERO_LENGTH_BYTE_ARRAY = new byte[0];
>
>Regards,
>
This assumes that there is no difference between null (no response body
exists) vs a returned response of length 0. I'm not sure this is the
case and I think we do need to differentiate between the two.
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [httpclient] question regarding HttpMethod interface: getResponseBody method
Posted by "Sean C. Sullivan" <se...@seansullivan.com>.
From: "dIon Gillard" <di...@multitask.com.au>
>
> Sean C. Sullivan wrote:
>
> >Currently, HttpMethod.java (an interface) defines a
> >method called "getResponseBody":
> >
> > /**
> > * Return my response body, if any,
> > * as a byte array.
> > * Otherwise return <tt>null</tt>.
> > */
> > public byte[] getResponseBody();
> >
> >
> >I would prefer if this method returns a zero-length array instead
> >of null.
> >
> >Returning a zero-length array is one of the API design tips that
> >is recommended in Josh Bloch's book:
> >
> > Effective Java Programming Language Guide
> > http://www.amazon.com/exec/obidos/ASIN/0201310058/
> >
> >
> >==> Item 27: Return zero-length arrays, not nulls
> >
>
> given I don't have the book handy, this doesn't make for a very
> convincing argument as to why we should change the API. [...]
>
> Can you please provide some more info on why you'd like the change?
>
First, I want the behavior of getResponseBody to be consistent with
the behavior of other "standard" (java.*) classes.
Example 1: java.util.Vector.toArray
The return value, Object[], will never be null.
Example 2: java.lang.String.getBytes
The return value, byte[], will never be null.
In Josh Bloch's book, "Effective Java Programming Language Guide",
Item 27 states:
Return zero-length arrays, not nulls
Rationale:
If the method sometimes returns null and other times returns a non-null array,
the programmer is forced to always check for null.
With the current HttpMethod interface, programmers must write:
byte[] result = hm.getResponseBody();
if (result != null)
{
processBody(result);
}
If we return a zero-length array instead of null, programmers can write:
byte[] result = hm.getResponseBody();
processBody(result);
> As well, the current api documents returning null. Which is cheaper from the
JVM
> perspective than creating a new byte array.
Bloch (page 134) writes:
"It is sometimes argued that a null return value is preferable to a
zero-length
array because it avoids the expense of allocating the array. This argument
fails
on two counts. First, it is inadvisable to worry about performance at this
level
unless profiling has shown that the method in question is a real contributor
to
performance problems. Second, it is possible to return the same zero-length
array from every invocation that returns no items because zero-length arrays
are immutable and immutable objects may be shared freely."
Solution: declare a static zero-length array variable
private final static byte[] ZERO_LENGTH_BYTE_ARRAY = new byte[0];
Regards,
-Sean
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [httpclient] question regarding HttpMethod interface: getResponseBody method
Posted by dIon Gillard <di...@multitask.com.au>.
Sean C. Sullivan wrote:
>jakarta-commons httpclient inquiry:
>
>
>Currently, HttpMethod.java (an interface) defines a
>method called "getResponseBody":
>
> /**
> * Return my response body, if any,
> * as a byte array.
> * Otherwise return <tt>null</tt>.
> */
> public byte[] getResponseBody();
>
>
>I would prefer if this method returns a zero-length array instead
>of null.
>
>Returning a zero-length array is one of the API design tips that
>is recommended in Josh Bloch's book:
>
> Effective Java Programming Language Guide
> http://www.amazon.com/exec/obidos/ASIN/0201310058/
>
>
>==> Item 27: Return zero-length arrays, not nulls
>
Hi Sean,
given I don't have the book handy, this doesn't make for a very
convincing argument as to why we should change the API. As well, the
current api documents returning null. Which is cheaper from the JVM
perspective than creating a new byte array.
Can you please provide some more info on why you'd like the change?
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [httpclient] minimum supported JDK version
Posted by dIon Gillard <di...@multitask.com.au>.
Sean C. Sullivan wrote:
>What is the minimum supported JDK version for
>the HttpClient class library?
>
From status.html, JDK 1.2 for run time, although the 'external'
interface is 1.1 compliant.
>
>
>Will HttpClient run on JDK 1.1.x?
>
Not sure. I'm certain it won't compile on it. Use of List etc...
>
>
>Is the intent to avoid using any JDK 1.2.x features
>so that the library will run on JDK 1.1.x?
>
Not AFAIK.
>I have some changes that I'd like to make to HttpClient.
>My changes assume that JDK 1.2.x is the minimum JDK environment.
>
>Please advise.
>
>Regards,
>
>-Sean
>
Could you also try to include some more info with your patches on
why/what is being patched. It's hard sometimes to have to read the patch
and work out what's being changed, rather than a short blurb in the
patch posting itself.
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[httpclient] minimum supported JDK version
Posted by "Sean C. Sullivan" <se...@seansullivan.com>.
What is the minimum supported JDK version for
the HttpClient class library?
Will HttpClient run on JDK 1.1.x?
Is the intent to avoid using any JDK 1.2.x features
so that the library will run on JDK 1.1.x?
I have some changes that I'd like to make to HttpClient.
My changes assume that JDK 1.2.x is the minimum JDK environment.
Please advise.
Regards,
-Sean
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[httpclient] question regarding HttpMethod interface: getResponseBody method
Posted by "Sean C. Sullivan" <se...@seansullivan.com>.
jakarta-commons httpclient inquiry:
Currently, HttpMethod.java (an interface) defines a
method called "getResponseBody":
/**
* Return my response body, if any,
* as a byte array.
* Otherwise return <tt>null</tt>.
*/
public byte[] getResponseBody();
I would prefer if this method returns a zero-length array instead
of null.
Returning a zero-length array is one of the API design tips that
is recommended in Josh Bloch's book:
Effective Java Programming Language Guide
http://www.amazon.com/exec/obidos/ASIN/0201310058/
==> Item 27: Return zero-length arrays, not nulls
Regards,
-Sean
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[httpclient] parameter validation, NullPointerException vs IllegalArgumentException
Posted by "Sean C. Sullivan" <se...@seansullivan.com>.
From: "dIon Gillard" <di...@multitask.com.au>
>
> Sean C. Sullivan wrote:
>
> >NameValuePair.java
> >
> >--------------------------
> >
> > /**
> > * Constructor.
> > */
> > public NameValuePair(String name, String value) {
> >
> > this.name = name;
> > this.value = value;
> >
> > }
> >
> >--------------------------
> >
> >With this constructor, it is allowable for a caller to do this:
> >
> > NameValuePair nvp = new NameValuePair(null, null);
> >
> >I would prefer if the NameValuePair constructor did not allow null
parameters.
> >
> >I prefer this constructor:
> >
> > /**
> > * Constructor.
> > */
> > public NameValuePair(String name, String value) {
> >
> > if (null == name) {
> > throw new NullPointerException("name parameter is null");
> > }
> > if (null == value) {
> > throw new NullPointerException("value parameter is null");
> > }
> >
> > this.name = name;
> > this.value = value;
> >
> > }
> >
> >
> Again,
>
> my call would be if these are illegal arguments, it should throw
> IllegalArgumentException, not NullPointerException.
In the core Java packages (java.*), Sun throws a NullPointerException
when a null parameter is unexpectedly detected:
Example: java/io/File.java
////////////////////
public File(String pathname) {
if (pathname == null) {
throw new NullPointerException();
}
/// .... etc .....
}
//////////
Also, Josh Bloch recommends throwing a NullPointerException
when a parameter is unexpectedly null ( "Item 23: Check Parameters for
Validity", [1], pages 120-121 ).
-Sean
[1] Effective Java Programming Language Guide by Josh Bloch
http://www.amazon.com/exec/obidos/ASIN/0201310058/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [httpclient] question regarding NameValuePair constructor, null parameters
Posted by Michael Smith <mi...@iammichael.org>.
From: dIon Gillard [mailto:dion@multitask.com.au]
> my call would be if these are illegal arguments, it should throw
> IllegalArgumentException, not NullPointerException.
NullPointerException makes perfect sense in that case. The API
documentation for NullPointerException specifically states it should be
used to indicate an illegal use of a null object. While
IllegalArgumentException is also applicable in the same sense -- an
illegal value. The difference, for me at least, is that a
NullPointerException provide more specific information as to what the
problem is. It's also more common in the JDK to see
NullPointerException thrown when a null argument is passed. In fact, I
can't think of any places where an IllegalArgumentException is thrown
when a null argument is passed, but know of a few where both are
declared (one for invalid objects passed in, and the other when a null
is passed).
For example:
http://java.sun.com/j2se/1.3/docs/api/java/lang/reflect/Array.html#get(j
ava.lang.Object,%20int)
declares it throws IllegalArgumentException *and* NullPointerException.
NullPointer if the arg is null, and IllegalArgument if the arg is not an
array.
regards,
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [httpclient] question regarding NameValuePair constructor, null parameters
Posted by dIon Gillard <di...@multitask.com.au>.
Sean C. Sullivan wrote:
>Jakarta-commons HttpClient inquiry:
>
>Why does the NameValuePair constructor allow
>null parameters?
>
>This is how the code currently looks:
>
>NameValuePair.java
>
>--------------------------
>
> /**
> * Constructor.
> */
> public NameValuePair(String name, String value) {
>
> this.name = name;
> this.value = value;
>
> }
>
>--------------------------
>
>With this constructor, it is allowable for a caller to do this:
>
> NameValuePair nvp = new NameValuePair(null, null);
>
>I would prefer if the NameValuePair constructor did not allow null parameters.
>
>I prefer this constructor:
>
> /**
> * Constructor.
> */
> public NameValuePair(String name, String value) {
>
> if (null == name) {
> throw new NullPointerException("name parameter is null");
> }
> if (null == value) {
> throw new NullPointerException("value parameter is null");
> }
>
> this.name = name;
> this.value = value;
>
> }
>
>
Again,
my call would be if these are illegal arguments, it should throw
IllegalArgumentException, not NullPointerException.
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>