Error handling while parsing smiles

Hi


I am not sure which forum to ask this question in. I am using chemaxon.jchem.db.UpdateHandler class to update a database using smiles strings. These smiles strings may some times be invalid, My problem is the way the API handles invalid smiles here are the specifics





1) UpdateHandler.execute() throws a SQLException without any description as to what was wrong with the smiles string. It would be very useful to be


able to find out what exactly was wrong with the smiles string preferably with a custom exception ( could be a subclass of SQLException, that way you can do it without breaking backward compatibility)





2) The UpdateHandler.execute_NE() and UpdateHandler.execute() methods prints a Exception stack trace internally which is not desirable, is there any way to stop this stack trace from being printed?





Here is the code that I am currently using to update the database

Code:

if ( (lines.length == 2) && SMILESRecognizer.canBeSMILES(lines[0]) )             {                System.out.println("Adding smiles "+lines[0]);                //set the smiles string                handler.setStructure(lines[0]);                //set the node id                handler.setValueForAdditionalColumn(1, lines[1]);                handler.execute_NE();             }

This question relates to JChem. I have moved it to the JChem forum.

Hi


Could you give me a link to where you posted it


Thanks


Wiraj

Dear Wiraj,





This is the place where your question will be answered soon by an expert, you don't need to follow another link.





Best Regards,


Erika.

Hi,

Quote:

1) UpdateHandler.execute() throws a SQLException without any description as to what was wrong with the smiles string.

Well, hopefully there should be something in the message, but I agree that is not always enough information, and not something you want to parse by code.

Quote:

It would be very useful to be able to find out what exactly was wrong with the smiles string preferably with a custom exception ( could be a subclass of SQLException, that way you can do it without breaking backward compatibility)

Well, until the last level it is coming up as MolFormatException, then it is re-thrown by SQL exception for backwards-compatibility indeed.


MolFormatException currently extends IOException and we cannot really add an other ancestor.


We will think about the best solution, probably a new method phasing out the execute(...) methods would be needed - this would go well with the need of returning some kind of ExecutionResult object.

Quote:

2) The UpdateHandler.execute_NE() and UpdateHandler.execute() methods prints a Exception stack trace internally which is not desirable, is there any way to stop this stack trace from being printed?

Currently there is no way to stop those error messages ending up on the standard error. This part of the code is pretty old, back then we did not package exceptions into each other, and had to preserve the trace before re-throwing.


We plan to revise these and logging in general in our code.








For now I suggest to try to import the SMILES strings with MolImporter first. If you get a MolFormatException, it is an invalid one.





http://www.chemaxon.com/jchem/doc/api/chemaxon/formats/MolImporter.html#importMol(java.lang.String)





To save an extra SMILES -> Molecule conversion, set the Molecule for UpdateHandler with setInputMolecule():





http://www.chemaxon.com/jchem/doc/api/chemaxon/jchem/db/UpdateHandler.html#setInputMolecule(chemaxon.struc.Molecule)





Please note that you still have to specify the input string with setStructure(...) as usual (this goes to the cd_structure column).





Best regards,





Szilard