Open sneumann opened 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.
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.
Hi, is there a policy or examples how backends handle parsing errors ?
stopifnot()
? ReturnNULL
? Throw Exceptions ? Yours, Steffen