Java exceptions thrown when extracting the shared library in NativeLibraryLoader.loadLibrary is swallowed by RockDB Java class

[tdas]

Expected behavior

Generally, when a Java exception is caught and rethrown as a different exception, the new exception has the caught exception as the cause. It is expected that if NativeLibraryLoader.loadLibrary throws an error while loading the library, RocksDB java class will expose that underlying exception.

Actual behavior

Error while loading native library from Java cannot be debugged correctly as RocksDB Java class swallows the IOException thrown by NativeLibraryLoader.loadLibrary. This is pretty obvious in this line.

This causes the final thrown exception to be like this.

...
Caused by: java.lang.RuntimeException: Unable to load the RocksDB shared libraryjava.nio.channels.ClosedByInterruptException
  at org.rocksdb.RocksDB.loadLibrary(RocksDB.java:67)
  at org.rocksdb.RocksDB.<clinit>(RocksDB.java:35)
  ... 73 more

Only the name of the underlying exception ClosedByInterruptException is printed, and not its stack trace.

The fix should be something like this.

- throw new RuntimeException("Unable to load the RocksDB shared library" + e);
+ throw new RuntimeException("Unable to load the RocksDB shared library", e);

Steps to reproduce the behavior

Not sure, as I am not able to debug why loading the library failed. However, this reproduce this issue of swallowed exceptions, any failure to load the library should be sufficient to show the problem.

[adamretter]

Yes this looks like a mistake, I would think that:

throw new RuntimeException("Unable to load the RocksDB shared library" + e);

should have been:

throw new RuntimeException("Unable to load the RocksDB shared library", e);

Would you care to send a PR?

[tdas]

#4728