Throw Exceptions instead of Errors

[fabiankessler]

Currently there are some open issues where MapDB throws an Error. A quick search brought up these recent ones:

AssertionError:
#513
#515
#509
#451

IOError:
#514

Even if these issues are not fixed soon, I recommend to catch and throw an exception instead.
Because of an Error an application using MapDB aborts. With an exception the app could detect an issue in MapDB, and drop the whole storage, without knowing what exactly went wrong, and start over with a fresh one.

[bwzhang2011]

+1

[jankotek]

There is long discussion about checked/unchecked exception. MapDB implements Map interface so we must wrap IOException into IOErrors.

MapDB simple expects IO errors to be inrecoverable. Users should close and reopen the store. WAL should be replayed in case of errors etc. It is too low-level and there is not really option to add something better without more layers and overhead.

MapDB 2.0 is better. It outputs warnings into logger. It also has exception hierarchy with better error messages. Assertions will also give better description.

Also MapDB 2.0 file format is much more robust. There are checksums and bit parity checks, so it detects data corruption much earlier.

[jankotek]

MapDB 2.0 now has exception hierarchy. It throws different exceptions for different types of errors.

[rage-shadowman]

@jankotek, the discussion about checked/unchecked exceptions is irrelevant. This is about Error being thrown (as opposed to some extension of RuntimeException -- neither of which are checked).

[jankotek]

I understand. The `DBException`, root of exception hierarchy in MapDB 2, extends `RuntimeException`.