Re: DataBuffer constructors

[Mark Wielaard <mark at klomp dot org>]

Hi,

On Fri, 2004-08-27 at 01:35, David Gilbert wrote:
> The consequences of using null arguments in these constructors are not
> specified anywhere.  Classpath and JDK 1.4 appear to be consistent with
> each other except in the DataBufferUShort class.  In the tests I'm
> submitting, this shows up as 2 failures in Classpath, but without a
> clear spec the tests could just as easily be reversed to show failures
> in Sun's implementation.
> 
> Anyone have any guidance on how this should be treated in Mauve?

Nasty. As a matter of style I like the behavior of the DataBufferUShort
constructor. Fail fast when you get a null bank since obviously the
DataBuffer isn't useful anyway. But the fact that not all DataBuffers do
this consistently is bad.

What I would do is to test that if you construct a concrete DataBuffer
with a null bank and then try to getElem() on it you must get a
NullPointerException. And in the test you don't care if when it is
precisely thrown:

    boolean pass = false;
    try
    {
      DataBufferShort b1 = new DataBufferShort((short[]) null, 1, 0);
      int ignore = b1.getElem(0);
    }
    catch (NullPointerException e)
    {
      pass = true;
    }
    harness.check(pass);

Since the important thing to test is that you don't get garbage
elements.

Cheers,

Mark

Attachment: signature.asc
Description: This is a digitally signed message part