Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error handling in Backends #29

Open
sneumann opened this issue Sep 10, 2020 · 2 comments
Open

Error handling in Backends #29

sneumann opened this issue Sep 10, 2020 · 2 comments

Comments

@sneumann
Copy link

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

@lgatto
Copy link
Member

lgatto commented Sep 10, 2020

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants