rformassspectrometry / RforMassSpectrometry

The R for Mass Spectrometry meta-package
https://rformassspectrometry.github.io/RforMassSpectrometry/
16 stars 8 forks source link

Error handling in Backends #29

Open sneumann opened 4 years ago

sneumann commented 4 years ago

Hi, is there a policy or examples how backends handle parsing errors ? stopifnot() ? Return NULL ? Throw Exceptions ? Yours, Steffen

lgatto commented 4 years ago

Backends don't necessary parse anything. It does happen when the data are read from mzML files (via mzR) and mgf files (via code in the MsBackendMgf package). In the former case, the parsing error is thrown by mzR. In the latter, it's will be the error from whatever base R function that hits an error.

So no, there is no explicit policy. While it might be a good idea and worth discussion, parsing is such a rather small part of the backend implementations that it might not be worth the investment.

jorainer commented 4 years ago

No policy (yet). In general I would avoid returning NULL in a function. If a function is supposed to return e.g. a matrix it's better to return a matrix with 0 rows instead of NULL. This means for MsBackend methods: they should always return the data type that is expected from them (e.g. peaksData should return a list - even if eventually empty).

If there is an unexpected problem in the backend it should throw an error. The Spectra package does not do any additional data checking but relies on the backend to provide correct data.

Regarding parsing: in MsBackendHmdb I throw an error if the input xml file e.g. does not contain m/z or intensity values or if they are not sorted. There is however also an option nonStop that, if set to nonStop = TRUE, converts the error to a warning. This is useful when reading the ~ 500,000 xml files from HMDB. You might not want to break the whole import operation if one file is faulty (in fact there are some such files). I think the backend developer knows best what errors to throw and what errors might happen (depending on the input files).

Maybe it's a good idea we would add a error handling section to the documentation.