I searched Phoenix code base - there is no reference to OrderedBytes.

On Thu, Oct 13, 2016 at 6:45 PM, Daniel Vimont <dan...@commonvox.org> wrote:

> Agreed, Ted. But I wanted to be sure there wasn't some hidden reason for
> the current "assert"-only code. The only other possibility that came to
> mind is that there may be some interoperability issue(s) with external
> consumers of OrderedBytes (such as Phoenix) which requires that no
> exception be thrown by some of the #decode methods. Hoping that Nick D. can
> perhaps provide the final word on this.
>
>
> On Fri, Oct 14, 2016 at 9:29 AM, Ted Yu <yuzhih...@gmail.com> wrote:
>
> > I think throwing exception should be the action to take.
> >
> > Relying on assertion is not robust.
> >
> > > On Oct 13, 2016, at 5:06 PM, Daniel Vimont <dan...@commonvox.org>
> wrote:
> > >
> > > 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