Add design doc for error handling

exploration/error-handling.md

@@ -42,8 +42,20 @@ In both languages, built-in error handling assumes a singular error.
 ICU4X operates in low resource environments for which returning at most 1 error is desirable
 because returning more than 1 error would require heap allocation.
 * Programming conventions and idioms: in [feedback from ICU-TC](https://docs.google.com/document/d/11yJUWedBIpmq-YNSqqDfgUxcREmlvV0NskYganXkQHA/edit#bookmark=id.lx4ls9eelh99),
-they found over the 25 years of maintaining the library that there was more cost than benefit in providing a default best effort return value at the same time as providing error information.
-The additional constraint in ICU4C's C++ style to return an error code rather than throwing errors using the STL further complicates the usefulness and likelihood to be used correctly during nested calls.
+they found over the 25 years of maintaining the library that there was more cost than benefit in additionally providing error information with a default best effort return value compared to just returning the default best effort value.
+The additional constraint in ICU4C's C++ style to return an error code rather than throwing errors using the STL further complicates the usefulness and likelihood to be used correctly by developers, especially during nested calls.
+
+> [!NOTE]
+> The wording in this document uses the word "signal" in regards to providing
+> information about an error rather than "return" or "emit" when referring to
+> a requirement that an implementation must at least indicate that an error has
+> occurred.
+> The word "signal" better accomodates more alternatives in the solution space
+> like those that only choose to indicate that an error occurred,
+> while still including those that additionally prefer to return the error
+> itself as an error object.
+> (By contrast, "return an error" implies that an error object will be thrown or
+> returned, and "emit an error" is ambiguous as to what is or isn't performed.)
 
 ## Proposed Design
 
@@ -83,6 +95,33 @@ This alternative establishes constraints that would contravene the constraints t
 * execution environment constraints
 * experience-based programming guidelines
 
+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
+
+> 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.
+
+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).
+
+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.
+
+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
 
 > When encountering an error during formatting,