Optimizing data module.

[Pacmens]

When looking through some code i found some locations where the code of the data module can be optimized.

This shouldn't impact functional for dependant modules but make it cleaner for them to use the modules functionality.

One example of this is just giving null back when there is no result wich leads to uper classes throwing NullPointerExceptions. It would be way nicer if it threw a custom RuntimeException that includes some details on the request failing. RuntimeException so it doesn't require the insertion of try catches everywhere.

[Pacmens]

Other than the null return there is also this little code that bothered me in the StorageAccessUnit class:

the casting done on line 67 is unnecessary in every way since the dao already returns a list of a type. Also the test of null is irrelevant since null is castable.

With a small change to the retryOnFail method namely by adding a new generic parameter to it as in and output here

so by channing line 124 to: protected <K> K retryOnFail(Callable<K> callable) {

you can simplify the whole get method to:

try {
    return retryOnFail(() -> dao.get(id));
} catch (FailedAfterRetriesException e) {

[Pacmens]

decided not to remove the return null for now. case to be made for and against it. may be done if #268 proves to be usefull enough