jep
jep copied to clipboard
SharedInterpreter constructor does not fulfill its contract
Describe the bug SharedInterpreter constructor does not fulfill its contract. It should throw JepException when jep is not in java.library.path, but it throws java.lang.UnsatisfiedLinkError instead. here is the problem
To Reproduce
- jep should not be installed
- create an instance of SharedInterpreter:
Jep jep = new SharedInterpreter();
Expected behavior Constructor throws JepException
Environment (please complete the following information): Any
I disagree that this is an issue. UnsatisfiedLinkError is more precise in telling you what went wrong than a JepException. And an Error is appropriate since it indicates a bad state of things, not something an application can easily recover from (without outside intervention of installing jep).
Hello @ndjensen,
Although the UnsatisfiedLinkError is a subtype of Error, it does not feel nearly as serious as some of the other possible jvm errors. I think it'd be better if it was up to the developer to decide if they can recover or not. Currently one does an ordinary try-catch block expecting to catch JepException in case something goes wrong. In my opinion the error should be wrapped inside of JepException and include error's message and stacktrace - it won't loose any verbosity that way.
If you feel the proposed approach is wrong, then the occurring errors could be at least mentioned in the SharedInterpreter constructor javadoc.
Cheers!