I'm currently looking into the various implementations of `DataType` in
hbase-common, and I just wanted to get confirmation of something before I
open up a JIRA and fix what **appear** to be bugs in the underlying
OrderedBytes
code.

All `DataType` implementations have their own overrides of the `#decode`
method. Some of these throw an appropriate exception when an invalid
byte-array is passed to them; for example:

*Number bogusNumeric = OrderedNumeric.ASCENDING.decode(new
SimplePositionedMutableByteRange(Bytes.toBytes("xyzpdq")));*

(This throws an IllegalArgumentException: "unexpected value in first byte:
0x78".)

But for other implementations, *no* validation is done; for example:

*Short bogusShort = OrderedInt16.ASCENDING.decode(new
SimplePositionedMutableByteRange(Bytes.toBytes("xyzpdq")));*

(This returns a short value of 1669, without complaint -- by ignoring the
first invalid "header" byte and constructing the value 1669 from the two
bytes that follow.)

In those implementations which lack validation, there are "assert"
statements in the place where I would expect an exception to be explicitly
thrown (or, in the context of OrderedBytes, one would expect the
#unexpectedHeader
method to be invoked, which in turn throws the exception). I just wanted to
check to make sure whether (perhaps for the sake of extreme efficiency?)
some validations in HBase low-level processing are intentionally being done
via bypassable "assert" statements instead of the throwing of exceptions.

Thanks!

Dan


[image: --]

Daniel Vimont
[image: https://]about.me/dvimont
<https://about.me/dvimont?promo=email_sig&utm_source=email_sig&utm_medium=external_link&utm_campaign=chrome_ext>

Reply via email to