Hi Ted:
Thanks for your reply.
The first 5 failing test is due to a null value in the top level (when
constructing the object), though
not in the argument place. The test case generated by the tool reveals a
corner case like:
Closure var0 = null;
Closure[] var1 = new Closure[]{var0};
ChainedClosure var2 = new ChainedClosure(var1), //the constructor
var2.execute( a not null object here); //it crashes, and throws a null
pointer exception
I think if an array containing null value (like var1) is not allowed, the
constructor should check
its validity when initializing the object, instead of propagating the
effect to the code when client calls it.
For example, the constructor line could check the nullable of each array
element, and throws
illegal argument exception if null is found. That might be a better
implementation to fulfill the
design contract. What do you think about this?
The last few cases (test433, test175, test76, test399) do not have a null
on the top level, but the
method under test still throws a NPE. Could you please check that? For
example,
we could simplify the test433 to the following code snippet (just remove
irrelevant code,
sorry that the tool is not smart enough to keep the test code minimal)
None of the variables appearing in this test is null, i think.
public void test433() throws Throwable {
org.apache.commons.collections.ExtendedProperties var0 =
new org.apache.commons.collections.ExtendedProperties();
java.lang.String var1 = "testNothing";
org.apache.commons.collections.BulkTest var2 =
new org.apache.commons.collections.BulkTest(var1);
java.lang.Integer var3 = new java.lang.Integer(5);
org.apache.commons.collections.bidimap.DualTreeBidiMap var24 =
new
org.apache.commons.collections.bidimap.DualTreeBidiMap((java.util.Map)
var0);
java.util.Map var26 =
org.apache.commons.collections.MapUtils.multiValueMap((java.util.Map)
var24);
org.apache.commons.collections.map.SingletonMap var27 =
new org.apache.commons.collections.map.SingletonMap();
// Checks that no java.lang.NullPointerException is thrown.
try {
var24.putAll((java.util.Map) var27);
} catch (java.lang.NullPointerException e) {
fail("Statement throw java.lang.NullPointerException.");
}
}
Thanks for your time. Your comments are highly appreciated.
thanks
-Sai
On Tue, Aug 17, 2010 at 5:23 PM, Ted Dunning <ted.dunn...@gmail.com> wrote:
> But it looks to me like you have null values embedded in the inputs.
>
> I think the same would happen if you called Arrays.sort and some of the
> objects in the array being sorted were null.
>
> Why do you think that non-nullity of the top level arguments is all that
> matters?
>
> On Tue, Aug 17, 2010 at 1:30 PM, Ted Dunning <ted.dunn...@gmail.com>
> wrote:
>
> > The 10 tests presented in the attachments violates one of the common Java
> > code practices (at least in my viewpoint):
> > if all the inputs are not null, there should not be null pointer
> exception
> > thrown.
> >
>
