Someone could design an API like (in pseudocode). I'd argue that such an
API should be allowed to be conformant. In particular, what the formatter
is expected to do can depend on what the caller tells it to do.
try {
x = format(X, parameters);*
// do something with it
}catch (MFException e) {
if (showMessageAnyway) {
x = formatWithFallback(X, parameters);*
} else if (showMissingMessage) {
x = reportMissingMessage(Xid, parameters);
} else {
logMessage("...", X, parameters)
throw e;
}
}
On Thu, May 16, 2024 at 2:38 PM Eemeli Aro @.***> wrote:
@.**** requested changes on this pull request.
This is going to need a design doc to explain the change.
At the moment, the spec is providing exactly one choice for what an MF2
formatter is expected to do when a runtime error occurs: Provide some
representation of the message, and separately report the error or errors.
The proposed change would be to remove this requirement completely, and
allow any of the following to occur:
A message with fallback contents is provided, and errors are
swallowed.
A message with fallback contents is provided, and errors are also
emitted.
No message is provided, and an error is emitted.
I don't think that's a good idea, and I think this is something on which
it's appropriate for us to be opinionated.
Someone could design an API like (in pseudocode). I'd argue that such an API should be allowed to be conformant. In particular, what the formatter is expected to do can depend on what the caller tells it to do.
try {
On Thu, May 16, 2024 at 2:38 PM Eemeli Aro @.***> wrote: