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?
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