On Fri, Apr 23, 2010 at 1:22 AM, tsuna <tsuna...@gmail.com> wrote: > On Thu, Apr 22, 2010 at 10:51 PM, Cosmin Lehene <cleh...@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. Thanks, St.Ack > 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 >
