hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Release killed... RC3 coming soon WAS -> Re: [VOTE] Shall we release hbase-0.20.4 Release Candidate 2 as hbase-0.20.4? (WAS --> Re: [VOTE] Shall we release hbase-0.20.4 Release Candidate 1 as hbase-0.20.4?)
Date Sat, 24 Apr 2010 19:47:59 GMT
On Fri, Apr 23, 2010 at 1:22 AM, tsuna <tsunanet@gmail.com> wrote:
> On Thu, Apr 22, 2010 at 10:51 PM, Cosmin Lehene <clehene@adobe.com> wrote:
>> I've noticed there are more places where exceptions tend to be eaten, or transformed
in a generic IOException. Working around this tends to obscure logic sometimes.  More, most
of the classes seem to both catch and throw IOException as a "standard". Perhaps working a
bit towards having a richer set of IOException subclasses would make sense. Anyone thought
of that?

+1  Maybe a bit of design first that lists the set of possible
exceptions (ScannerTimeoutException, WrongRegionException) and then
issues to bring us in-line w/ a specification?  You want to open an
issue Cosmin with say an example of where we are wrong for
illustration?  Throw Benoît's comment below in there too?

My sense is that a combination of lazyness -- "Well, IOE is going to
be *handled* anyways" -- and a lack of agreement about what is the
right way to do it has gotten us to here.


> I totally agree.  HBase's use of exceptions (both internally and in
> the client API) is Just Wrong.  Virtually everything throws an
> IOException and hardly any method documents what it may really
> represent, so writing proper recovery code is almost impossible (you
> can always give up or retry, but you don't really know what kind of
> problem you're dealing with).  And of course IOException is a checked
> exception, which means you are *forced* to handle it, even though you
> almost never know what to do with HBase's IOEs.
> --
> Benoit "tsuna" Sigoure
> Software Engineer @ www.StumbleUpon.com

View raw message