EAO: Are you saying that the ICU mandates that a fallback is returned?

EAO: The spec text on formatting says that, "In all cases, when encountering a runtime error, a message formatter MUST provide some representation of the message. An informative error or errors MUST also be separately provided."

TIM: It’s true that ICU can only concurrently return one error. I want to know where we require multiple errors to be returned.

RGN: Yes, I agree. The other JS Intl APIs provide a fallback value or best effort return value when formatting. But it makes sense to me that MessageFormat is different enough that it would be useful to return the error in addition to returning a value.

ECH: I'd like to understand RGN's reasoning on what makes MessageFormat different from the other JS Intl APIs in his mind, that MessageFormat should return the error(s) and a return value when the other APIs don't.

RGN: I think it's the impact of MessageFormat. MessageFormat will in turn call the other APIs, so the scope of the API is bigger, and the ways that the API to go wrong is greater.

EAO: In addition, because MessageFormat depends on user data, the distance between the developer and the user's localized experience is much greater. If an error is introduced during translation, it might not even be possible to catch that in CI systems or elsewhere, before it goes to production.

ECH: In one way, MessageFormat is a formatter just like all of the other i18n APIs in JS Intl. I understand the argument the argument that the scale warrants different behavior, but that is only one way of looking at it.

Another way of looking at it is in terms of how actionable an error message is to the person it bubbles up to. In the example that MIH brought up earlier, an end user can't do much when the browser throws an exception on input HTML, so the browser has to make its best effort to render. Another example is ICU, which is in that same category as a browser since it is a library that is depended on by other applications, so it can't throw exceptions that take down the entire dependent application. That's why it has provides best effort results.

So in the second way of looking at things, if we really care about returning errors, an alternative approach could be to provide two different types of formatting APIs, one that provides a best effort like the other JS Intl and ICU APIs do, and another one that is allowed to throw exception. But there's not one way to look at things.

RGN: Yes, and to be clear, I am not opinionated about which approach we would take. I see both of those approaches as being a part of the same solution space.

TIM: This discussion means that #738 will be blocked on an issue that MIH will raise.