Define scope of public API for errors

[romaricpascal]

What

Decide which parts of the errors we throw (base class, individual error classes, error names, error messages) are part of our public API and which do not.

Each part allows service teams different things:

• base class allow a generic instanceof to separate our errors from native errors
• individual error classes do the same, but allow to separate each kind of error
• error names allow to separate each kind of error, without exposing the classes
• error message allow to potentially distinguish individual errors of the same type (eg. an element missing from the CharacterCount from an element missing from the Accordion)

Why

Before we release v5, we to provide our users clarity on which parts are public (and as such will only be updated through a breaking change) and which are not (and we may change at will).

Who needs to work on this

Developers

Who needs to review this

Developers

Done when

• We've made a decision on the matter.
• We've documented the public API in the Frontend Docs

[romaricpascal]

Following our discussion at dev catch-up, we settled on starting with throwing errors, but the content of the error fields are not part of our public API. That means they're subject to change without them being a breaking change. If needs get to our attention for having fields to programmatically distinguish errors we’ll looking into introducing a way in our public API for teams to distinguish between errors.

For reference: the (private) discussion document around our options.

Closing as that sorts us out for v5, we can open a new issue if/when needs arise to have specific parts of the errors as our public API.