This is the mail archive of the
mauve-patches@sources.redhat.com
mailing list for the Mauve project.
Re: DataBuffer constructors
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