HBASE-2519. Expose IOEs up to client

Review Request #75 - Created May 21, 2010 and submitted

Todd Lipcon
In particular fixes issues where a compaction that got an error on one storefile would happily proceed and just remove all that data. Or a user scan would just show empty results instead of an error.
new unit tests
  2. why are we creating a reader here? The incoming store file list is already opened... Re-opening the file might not be the best choice, since if the on-disk situation becomes different from the in-memory we should probably be failing the compactions.  Thus the code should be like what it was before only throwing an exception instead of continuing on.
    1. createReader is lazy - if the file is already open it returns the existing one. I changed to create() since it was handy to use from the tests (and some other patches on top of this use it in that way as well)
  3. remove this pointless catch, it just muddles the stack trace
    1. The point of this is that you get the toString of the StoreFileScanner, which includes path name, etc. Otherwise you often get a less useful error like "Could not get block locations for blk_234234, aborting". So while the stack trace is definitely longer, I think there is actual value in having as much information here as possible.
  4. ditto, remove the try/catch and let the exception bubble up
  2. There are 2 spaces before `throws', need just 1.
    1. Just testing review board.  Follow up test.
  1. One more test.
    Also I hope we're going to fix the whole situation with IOExceptions all over the place.  They're defeating the whole purpose of checked exceptions are *really* annoying in client code (code that uses HBase).
  2. i didnt note that, ok then lets keep it
    1. This patch is radical.  Its going to throw up some new stuff.  Best to get it in now.  I had two minor issues.  I can fix on commit.
  2. Why not remove the try/catch and just let the IOE out?
  3. Same here (Remove the try/catch and just let the IOE out)
  1. I'm going to commit this.