Emit errors on FluentBundle instances

[stasm]

Rather than passing an errors array to format, we could emit errors on the FluentBundle instance.

[Pike]

That makes FluentBundle not reentrant, though? Probably not much of a problem in JavaScript, but as a general runtime API design, I don't think that's a good idea.

[stasm]

This is only intended for the JS implementation, yes :)

[Pike]

TBH, as long as we only have "one example implementation" to show how to do runtime, I'd recommend to not create APIs that are bad ideas in other languages.

[stasm]

We have three, and we'll have a reference one soon, too. I strongly feel that we should design the JS API to be the best in class for JS apps.

[stasm]

Can you expand a bit on what you mean by reentrant here? Do you use it as a proxy for thread-safe?

[Pike]

Not a proxy for, but a condition for thread-safety. https://en.wikipedia.org/wiki/Reentrancy_(computing)

[eemeli]

@stasm, could you clarify what you mean by "emit errors on the FluentBundle instance"? Would that mean throwing errors from e.g. bundle.format(), or having something like a bundle.onError() method to register a callback for error reporting?

[stasm]

Sorry, I should have been more specific. I meant the latter: bundle.onerror or bundle.addEventListener("error").

[Pike]

I just realized that this ties in to a pet peeve of mine, and that's runtime error fallback.

I think that not doing fallback on runtime errors is a bug. It's an OK shortcut to get gecko off the ground, but I don't think it's the right design choice.

Moving errors to an API "someone can know" makes it much more cumbersome to implement runtime-error-fallback based on FluentBundle.

[stasm]

While I don't agree with the premise that we should fall back on runtime errors, I see how switching to the emitter pattern would make that harder. I see FluentBundle as a low-level API which should allow many different use-cases and fallback strategies. Let's keep a way to easily query the errors on a per-format() basis. Currently this is done by passing the errors array as the last argument to format. I wonder what the performance impact of returning an array of errors in a {value, errors} tuple would be. Do you think that's something worth testing?

I'm not closing this issue yet because I also wonder if it would still make sense to emit errors on the bundle, independent of reporting them on a per-call basis. Would this be helpful for development and debugging, where you'd just attach an event listener to the bundle? For example, in fluent-react, the developer has access to bundles which they pass to <LocalizationProvider>, but they don't have access to the code calling format for individual messages.

[Pike]

We pass in the errors array to avoid having to allocate it for each call. We did that in 2513f00, bug 1301198.

[stasm]

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

[eemeli]

Would it not make sense to presume that errors are exceptional, and in a low-level API handle them in a JavaScript-appropriate way by throwing them? If that error includes a suggested fallback message, it allows any sort of API to be built on it, such as a higher-level error listener. Sure, this way doesn't allow for more than one error to be returned/thrown at a time, but if the functions only do one thing (e.g. addResource, getMessage, formatAttribute), are there really cases when more than one error would be expected?

Returning a tuple with an error, pushing errors into a prepared errors array and emitting errors to a listener all sound like they're rather opinionated and somewhat non-JavaScriptish ways of dealing with errors.

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