DataBuffer constructors

[David Gilbert]

On Fri, 2004-08-27 at 12:58, Mark Wielaard wrote:
> 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.

I agree, failing straight away would make the most sense.  Some of the
constructors do this (most of the ones that accept an 'array of arrays'
for the data banks).

> 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.

Ah, I like that idea.  It loosens the check just enough to cover both
the sensible behaviour and the actual behaviour in Sun's
implementation.  Which given (a) the absence of a clear spec and (b) the
amount of inconsistency in all these constructors, is probably the best
that can be done.

I'll update all the DataBuffer constructor tests and resubmit them.

A much more general question that this case raises for me, though:  when
something isn't specified, does it cause any trouble to write checks
based on the actual behaviour of Sun's implementation?  I'm wondering if
there is a point where that becomes "reverse engineering"...

Regards,

Dave