-
Notifications
You must be signed in to change notification settings - Fork 17
Description
Steve Roughley, Vernalis, has suggested the following interesting idea as it was successfully implemented already in the Vernalis nodes:
In the spirit of OSS/sharing etc I thought that this latest commit to the Vernalis code might be of interest:
vernalis/vernalis-knime-nodes@ebc1d9f
In particular this file - https://github.com/vernalis/vernalis-knime-nodes/blob/master/com.vernalis.knime.chem.core/src/com/vernalis/knime/chem/rdkit/RDKitRuntimeExceptionHandler.java
Basically this provides a mechanism for handling RDKit exceptions for either the new (4.1) or older versions of the RDKit Types plugin. Typical usage:
try{
//Do something throwing e.g. GenericRDKitException or MolSanitizeException…
} catch (MolSanitizeException e) {
// Just re-throw, but message is available via standard #getMessage() call
throw new RDKitRuntimeExceptionHandler(e);
} catch (GenericRDKitException e) {
// Just log the message…
getLogger().warn(new RDKitRuntimeExceptionHandler(e).getMessage());
}
Hope that’s of use…
Steve
I think this is a very good idea, but would require some amount of refactoring as we have to go through all RDKit nodes code and rework the error handling and automated tests - that would be a looong journey.
Steve had some other idea: Maybe we can make the #getMessage() work in the wrappers in RDKit – that would solve the problem for once and all. Then we can simply rely on having a meaningful message in all exceptions coming from RDKit.
If I understand it correctly, that would mean to improve the SWIG mechanism that creates the wrapper classes... - It will be more on the RDKit side, not so much on the RDKit Nodes side.