Currently mx can return a Result<T> object during translation, or it can throw. There is no nuance there and there is no way to use the Result mechanism from inside the reading and writing mechanisms. A better mechanism would allow an accumulation of errors, warnings and info statements depending on the severity of the issue encountered.
For example, in SpannerResolver.cpp, this is not well-aligned with the doctrine, nor would silence be a great option either:
case api::SpannerNumber::Kind::identity: {
const auto iter = myResolved.find(inObject);
if (iter == myResolved.cend())
{
MX_THROW("identity spanner was not visited by resolvePart; the writer would emit an "
"unnumbered spanner that could collide with another");
}
return iter->second;
}What might be better here is to add an error object to a context (or send it through a lambda in the case of a multithreaded application with, e.g. a live UI), that describes the error and when and where it was encountered. Then translation could continue and the caller could inspect their errors, warnings, and infos and let the application.
Throwing could then be reserved for cases where the translation really cannot proceed because the state is too bad to continue.
Note: the above example might not be the best one since perhaps that is a state that is too bad to continue, but the idea stands. Not every little mistake in the score data requires throwing, but it is the only mechanism we have.
Currently
mxcan return aResult<T>object during translation, or it can throw. There is no nuance there and there is no way to use theResultmechanism from inside the reading and writing mechanisms. A better mechanism would allow an accumulation of errors, warnings and info statements depending on the severity of the issue encountered.For example, in
SpannerResolver.cpp, this is not well-aligned with the doctrine, nor would silence be a great option either:What might be better here is to add an error object to a context (or send it through a lambda in the case of a multithreaded application with, e.g. a live UI), that describes the error and when and where it was encountered. Then translation could continue and the caller could inspect their errors, warnings, and infos and let the application.
Throwing could then be reserved for cases where the translation really cannot proceed because the state is too bad to continue.
Note: the above example might not be the best one since perhaps that is a state that is too bad to continue, but the idea stands. Not every little mistake in the score data requires throwing, but it is the only mechanism we have.