Thanks for checking into that, Ted. As I said, hopefully Nick D. can give
us the final word on this question.

On Fri, Oct 14, 2016 at 10:53 AM, Ted Yu <yuzhih...@gmail.com> wrote:

> 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