Eating exceptions seems like the wrong thing to do.  At least wrap the exception in a GdxRuntimeException.  Alternatively, throw a new wrapped SQLException type?   This is true for a lot of the other methods that can go wrong, too.  Silently eating the error seems like it will just create confusion and make it hard for developers to figure out what is going wrong.  I think you need to decide which places are errors that imply the programmer made a silly mistake (e.g., looking for a "blob" that isn't there) in which case you can throw an unchecked runtime exception.  For places where the programmer needs to deal with errors outside their code (e.g., cannot write to a database because storage is full or somesuch), then your APIs need to return some indication of the failure (either as a return code or as a checked exception).