fluent.js: Emit errors on FluentBundle instances

The original issue here was about emitting errors on bundle instance. There were a number of arguments against it, and the discussion evolved into a general discussion about error reporting. Thanks, everyone, for you input. I just merged #396 into the release branch for the next version of @fluent/bundle.

The change keeps the current error reporting behavior but makes it opt-in: by passing an errors array as the third argument to formatPattern, consumers of the API can collect more than one error from the operation, and can also rely on formatPattern always returning a string.

By default, OTOH, when the third argument is omitted, the first encountered error is thrown from formatPattern, as it was suggested by @eemeli.

I think we may close this issue now. Thanks again!

[…] are there really cases when more than one error would be expected?

I think this is the key question here. In the current design of the resolver, it’s completely possible that formatting a pattern results in more than one error:

• In addResource, we don’t want to stop adding messages if a single message causes an error (e.g. it’s a duplicate of another one).
• In formatPattern, foo = {$one} and {$two} can have two errors if neither $one nor $two are passed as arguments.

The fact that formatPattern always returns a string, even if it’s a best-effort attempt to resolve as much as it could, is an important part of Fluent’s design. Buggy translations must not break the app.

Or is there a clear and measured benefit from avoiding throw at any level of the API?

I just finished running some tests and indeed, I’m not seeing any impact on our tools/perf benchmarks. I’ve also tried to write a microbenchmark which looks similarly promising. I’ll need to confirm this still, but I think it means that we should be much more open to throwing errors and catching them in our code.

That said, as far as the public API is concerned, I think we should really consider the design goal of always returning a best-effort string from formatPattern. #390 suggested that throwing only happen when the errors argument is not present, which could be a good middle ground here.

Yeah, I remember. That was almost 3 years ago, however; the performance impact might be different today 😃