Add ballot options from unicode-org#830, designate selected design as such

Author: echeran

exploration/error-handling.md

@@ -77,57 +77,38 @@ However, `java.text.NumberFormat` provide both throwing and non-throwing
 As a MessageFormat implementer, I want to be able to signal errors in an idiomatic way
 for my language and still be conformant with MF2 requirements.
 
-## Proposed Design
+## Accepted Design
 
-The following spec text is proposed:
+The following design was selected in #830.
 
-> A message formatter MUST signal errors required by this specification.
-> It SHOULD provide the specific information for each error reported.
-> A message formatter SHOULD provide a fallback representation of the message.
->
-> [!NOTE]
-> The fallback representation of a message MAY be provided by a separate API.
-
-This solution requires implementations to be able to signal an error occurred,
-which can be accomplished in different ways. Ex:
-
-* an API that throws or returns an Error object when encountering an error
-* an API that includes a read/write `ErrorCode` argument 
-* two APIs, a permissive one that always returns a best-effort formatted result
-and a stricter one that throws or returns an Error object when encountering an error
-* an API that always returns a best-effort formatted result
-and sets a global `boolean` value
-
-This does not give implementations full freedom to return _nothing_ or some other behavior.
-
-## Alternatives Considered
+### MUST signal errors and MUST provide fallback
 
-### Separate Requirements
+* Implementations MUST provide a mechanism for signaling errors. There is no specific requirement for what form signaling an error takes.
+* Implementations MUST provide a mechanism for getting a fallback representation of a message that produces a formatting or selection error. Note that this can be entirely separate from the first requirement.
+* An implementation is not conformant unless it provides access to both behaviors. It is compliant to do both in a single formatting attempt.
 
-The following spec text is proposed:
+> In all cases, when encountering an error,
+> a message formatter MUST be able to signal an error or errors.
+> It MUST also provide the appropriate fallback representation of the _message_ defined
+> in this specification.
 
-> When formatting a message with one or more errors:
-> - An implementation MUST provide a way for a user to be informed
->   of the name of at least one of the errors,
->   either directly or via an identifying error code.
-> - An implementation MUST provide a way for a message with one or more
->   _Resolution Errors_ or _Message Function Errors_ to be formatted
->   using a fallback representation.
->
-> The two above requirements MAY be fulfilled by a single formatting method,
-> or separately by more than one such method.
+This alternative requires that an implementation provide both an error signal
+and a means of accessing a "best-effort" fallback message.
+This slightly relaxes the requirement of "returning" an error
+(to allow a locally-appropriate signal of the error).
 
-This alternative ensures that even messages with runtime errors
-can be formatted with the same string representation in all implementations.
+Under this alternative, implementations can be conformant by providing
+two separate formatting methods or functions,
+one of which returns the fallback string and one of which signals the error.
 
-Compared to the current spec text,
-the under-specified "informative error" is replaced
-with a more concrete minimum requirement,
-which can be fulfilled with a two-byte error code in very limited environments.
+Similar to the current spec text,
+this alternative requires implementations to provide useful information:
+both a signal that an error occurred and a best effort message.
+A downside to this alternative is that these requirements together assume that
+all implementations will want to pay the cost of constructing a representative mesage
+after the occurrence of an error.
 
-The phrase "In all cases" is left out,
-and the ability to fulfill the requirements separately
-rather than at the same time is explicitly called out.
+## Alternatives Considered
 
 ### Current spec: require information from error(s) and a representative best effort message
 
@@ -148,30 +129,23 @@ For example, in ICU,
 [the suggested practice](https://docs.google.com/document/d/11yJUWedBIpmq-YNSqqDfgUxcREmlvV0NskYganXkQHA/edit#bookmark=id.lx4ls9eelh99)
 is to avoid additionally returning optional error codes when providing best-effort formatted results.
 
-### Require a best-effort message value and signaling of an error
+### MUST signal errors and SHOULD provide fallback
 
-> In all cases, when encountering an error,
-> a message formatter MUST be able to signal an error or errors.
-> It MUST also provide the appropriate fallback representation of the _message_ defined
-> in this specification.
+* Implementations MUST provide a mechanism for signaling errors. There is no specific requirement for what form signaling an error takes.
+* Implementations SHOULD provide a mechanism for getting a fallback representation of a message that produces a formatting or selection error. Note that this can be entirely separate from the first requirement.
+* Implementations are conformant if they only signal errors.
 
-This alternative requires that an implementation provide both an error signal
-and a means of accessing a "best-effort" fallback message.
-This slightly relaxes the requirement of "returning" an error
-(to allow a locally-appropriate signal of the error).
+###  SHOULD signal errors and MUST provide fallback
 
-Under this alternative, implementations can be conformant by providing
-two separate formatting methods or functions,
-one of which returns the fallback string and one of which signals the error.
+* Implementations SHOULD provide a mechanism for signaling errors. There is no specific requirement for what form signaling an error takes.
+* Implementations MUST provide a mechanism for getting a fallback representation of a message that produces a formatting or selection error. Note that this can be entirely separate from the first requirement.
+* Implementations are conformant if they only provide a fallback representation of a message.
 
-Similar to the current spec text,
-this alternative requires implementations to provide useful information:
-both a signal that an error occurred and a best effort message.
-A downside to this alternative is that these requirements together assume that
-all implementations will want to pay the cost of constructing a representative mesage
-after the occurrence of an error.
 
-### Allow implementations to determine all details
+### Error handling is not a normative requirement
+
+* Implementations are not required by MF2 to signal errors or to provide access to a fallback representation.
+    - The specification provides guidance on error conditions; on what error types exist; and what the fallback representation is.
 
 > When encountering an error during formatting,
 > a message formatter MAY provide some representation of the message,