From 1c5d62ea84212486bf7749202b36ba46864617fa Mon Sep 17 00:00:00 2001 From: Elango Cheran Date: Sun, 2 Jun 2024 23:57:46 -0700 Subject: [PATCH 01/14] Add design doc for error handling --- exploration/error-handling.md | 103 ++++++++++++++++++++++++++++++++++ 1 file changed, 103 insertions(+) create mode 100644 exploration/error-handling.md diff --git a/exploration/error-handling.md b/exploration/error-handling.md new file mode 100644 index 0000000000..c095e3d940 --- /dev/null +++ b/exploration/error-handling.md @@ -0,0 +1,103 @@ +# Error Handling + +Status: **Proposed** + +
+ Metadata +
+
Contributors
+
@echeran
+
First proposed
+
2024-06-02
+
Issues
+
#782
+
Pull Requests
+
#795
+
+
+ +## Objective + +Decide whether and what implementations "MUST" / "SHOULD" / "MAY" perform after a runtime error, regarding: + +1. information about error(s) + - including, if relevant, the minimum number of errors for which such information is expected +1. a fallback representation of the message + +## Background + +In practice, +runtime errors happen when formatting messages. +It is useful to provide information about any formatting error(s) back to the callsite. +It is useful to the end user to provide best effort fallback representation of the message. +Specifying the behavior in such cases promotes consistent results across conformant implementations. + +However, implementations of MessageFormat 2.0 will be faced with different constraints due to various reasons: + +* Programming language: the language of the implementation informs idiomatic patterns of error handling. +In Java, errors are thrown and subsequently caught in `try...catch` block. +In Rust, fallible callsites (those which can return errors) should return a `Result` monad. +In both languages, built-in error handling assumes a singular error. +* Environment constriants: as mentioned in [feedback from ICU4X](https://github.com/unicode-org/message-format-wg/issues/782#issuecomment-2103177417), +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 use error code rather than throwing errors using the STL further complicates the usefulness and likelihood to be used correctly during nested calls. + +## Proposed Design + +The following spec text is proposed: + +> In all cases, when encountering an error during formatting, +> a message formatter MUST provide some representation of the message, +> or MUST provide an informative error or errors. +> An implementation MAY provide both. + +This solution requires implementations to return _something_, +but it leaves the decision to the implementation whether to: + +* return an error (or errors) +* return a representative message +* return both + +This does not give implementations full freedom to return _nothing_ or some other behavior. + +## Alternatives Considered + +### Current spec: require information from error(s) and a representative best effort message + +The current spec text says: + +> In all cases, when encountering a runtime error, +> a message formatter MUST provide some representation of the message. +> An informative error or errors MUST also be separately provided. + +This alternative places constraints on implementations to provide multiple avenues of useful information (to the callsite and user). + +This alternative establishes constraints that would contravene the constraints that exist in projects that have implemented MF 2.0 (or likely will soon), based on: +* programming language idioms/constraints +* execution environment constraints +* experience-based programming guidelines + +### Allow implementations to determine all details + +> When encountering an error during formatting, +> a message formatter MAY provide some representation of the message, +> or it MAY provide an informative error or errors. +> An implementation MAY provide both. + +This alternative places no expectations on implementations, +which supports the constraints we know now, +as well as any possible constraints in the future +(ex: new programming languages, new execution environments). + +This alternative does not assume or assert that some type of useful information +(error info, representative message) +will be possible and should be returned. + +### Alternate wording + +> When an error is encountered during formatting, +> a message formatter can provide an informative error (or errors) +> or some representation of the message or both. \ No newline at end of file From d212fb710fd742489325ec9669b81443b8ee5f10 Mon Sep 17 00:00:00 2001 From: Elango Cheran Date: Mon, 3 Jun 2024 16:29:44 +0000 Subject: [PATCH 02/14] Apply suggestions from code review Co-authored-by: Addison Phillips --- exploration/error-handling.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/exploration/error-handling.md b/exploration/error-handling.md index c095e3d940..baa10907e5 100644 --- a/exploration/error-handling.md +++ b/exploration/error-handling.md @@ -28,7 +28,7 @@ Decide whether and what implementations "MUST" / "SHOULD" / "MAY" perform after In practice, runtime errors happen when formatting messages. -It is useful to provide information about any formatting error(s) back to the callsite. +It is useful to provide information about any errors back to the callsite. It is useful to the end user to provide best effort fallback representation of the message. Specifying the behavior in such cases promotes consistent results across conformant implementations. @@ -43,7 +43,7 @@ ICU4X operates in low resource environments for which returning at most 1 error 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 use error code rather than throwing errors using the STL further complicates the usefulness and likelihood to be used correctly during nested calls. +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. ## Proposed Design From 2fd70e45255770f9e1a59e265da2d4b4b24ac52f Mon Sep 17 00:00:00 2001 From: Elango Cheran Date: Thu, 6 Jun 2024 18:00:08 +0000 Subject: [PATCH 03/14] Update exploration/error-handling.md Co-authored-by: Tim Chevalier --- exploration/error-handling.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/exploration/error-handling.md b/exploration/error-handling.md index baa10907e5..994b0a9cf5 100644 --- a/exploration/error-handling.md +++ b/exploration/error-handling.md @@ -29,7 +29,7 @@ Decide whether and what implementations "MUST" / "SHOULD" / "MAY" perform after In practice, runtime errors happen when formatting messages. It is useful to provide information about any errors back to the callsite. -It is useful to the end user to provide best effort fallback representation of the message. +It is useful to the end user to provide a best effort fallback representation of the message. Specifying the behavior in such cases promotes consistent results across conformant implementations. However, implementations of MessageFormat 2.0 will be faced with different constraints due to various reasons: From 0b0e90cff79242f266c56e0f7f6cc29f6a00b32b Mon Sep 17 00:00:00 2001 From: Elango Cheran Date: Thu, 6 Jun 2024 16:29:53 -0700 Subject: [PATCH 04/14] Update text of proposed alternative to simplify and add incremental constraint --- exploration/error-handling.md | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/exploration/error-handling.md b/exploration/error-handling.md index 994b0a9cf5..0938213cde 100644 --- a/exploration/error-handling.md +++ b/exploration/error-handling.md @@ -49,17 +49,20 @@ The additional constraint in ICU4C's C++ style to return an error code rather th The following spec text is proposed: -> In all cases, when encountering an error during formatting, -> a message formatter MUST provide some representation of the message, -> or MUST provide an informative error or errors. -> An implementation MAY provide both. - -This solution requires implementations to return _something_, -but it leaves the decision to the implementation whether to: - -* return an error (or errors) -* return a representative message -* return both +> In all cases, when encountering an error, +> a message formatter MUST be able to signal an error or errors. +> It MAY also provide the appropriate fallback representation of the _message_ defined +> in this specification. + +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 a global `boolean` values This does not give implementations full freedom to return _nothing_ or some other behavior. From d55e19476cd175eb19c816b07a5d847fe9e646aa Mon Sep 17 00:00:00 2001 From: Elango Cheran Date: Fri, 7 Jun 2024 11:54:10 -0700 Subject: [PATCH 05/14] Reword to unambiguously convey correct summary --- exploration/error-handling.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/exploration/error-handling.md b/exploration/error-handling.md index 0938213cde..e286373e28 100644 --- a/exploration/error-handling.md +++ b/exploration/error-handling.md @@ -42,7 +42,7 @@ 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. +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 during nested calls. ## Proposed Design From 25f9fcdf1c0848ef0acd215a76aea228acb3b707 Mon Sep 17 00:00:00 2001 From: Elango Cheran Date: Mon, 10 Jun 2024 00:58:53 -0700 Subject: [PATCH 06/14] Add example of coding guidelines --- exploration/error-handling.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/exploration/error-handling.md b/exploration/error-handling.md index e286373e28..2d2eb536f2 100644 --- a/exploration/error-handling.md +++ b/exploration/error-handling.md @@ -43,7 +43,7 @@ ICU4X operates in low resource environments for which returning at most 1 error 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 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 during nested calls. +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. ## Proposed Design @@ -83,6 +83,10 @@ 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. + ### Allow implementations to determine all details > When encountering an error during formatting, From ade87356443f0ad637ecc549979520fced3d9ce1 Mon Sep 17 00:00:00 2001 From: Elango Cheran Date: Mon, 10 Jun 2024 11:26:56 -0700 Subject: [PATCH 07/14] Add paragraph indicating word choice of "signal" vs. "emit" & "return" --- exploration/error-handling.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/exploration/error-handling.md b/exploration/error-handling.md index 2d2eb536f2..2fbb859b32 100644 --- a/exploration/error-handling.md +++ b/exploration/error-handling.md @@ -45,6 +45,18 @@ because returning more than 1 error would require heap allocation. 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 The following spec text is proposed: From be5f9a0253ee243ec9dd9789a9efbe54d6035c09 Mon Sep 17 00:00:00 2001 From: Elango Cheran Date: Tue, 11 Jun 2024 14:20:53 -0700 Subject: [PATCH 08/14] Add additional alternative still maintaining both MUST clauses --- exploration/error-handling.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/exploration/error-handling.md b/exploration/error-handling.md index 2fbb859b32..9661e60325 100644 --- a/exploration/error-handling.md +++ b/exploration/error-handling.md @@ -99,6 +99,26 @@ 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 maintains that an implementation must both return a best-effort message +and must signal that an error has occurred. +Compared to the current text, +this alternative slightly loosens the constraint of +returning an error into only needing to signal an 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, From 6c9fff0a04caeded3a2b282711b769ad7214048c Mon Sep 17 00:00:00 2001 From: Elango Cheran Date: Wed, 12 Jun 2024 17:31:08 +0000 Subject: [PATCH 09/14] Update exploration/error-handling.md Co-authored-by: Addison Phillips --- exploration/error-handling.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/exploration/error-handling.md b/exploration/error-handling.md index 9661e60325..298cf2d6dd 100644 --- a/exploration/error-handling.md +++ b/exploration/error-handling.md @@ -106,11 +106,14 @@ is to avoid additionally returning optional error codes when providing best-effo > It MUST also provide the appropriate fallback representation of the _message_ defined > in this specification. -This alternative maintains that an implementation must both return a best-effort message -and must signal that an error has occurred. -Compared to the current text, -this alternative slightly loosens the constraint of -returning an error into only needing to signal an error. +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: From 5f7c3176da1f22b6ab59d2ec8f4b81d223c55302 Mon Sep 17 00:00:00 2001 From: Elango Cheran Date: Mon, 24 Jun 2024 16:21:12 +0000 Subject: [PATCH 10/14] Apply suggestions from code review Co-authored-by: Addison Phillips Co-authored-by: Eemeli Aro --- exploration/error-handling.md | 57 ++++++++++++++++++++++++++++++++--- 1 file changed, 53 insertions(+), 4 deletions(-) diff --git a/exploration/error-handling.md b/exploration/error-handling.md index 298cf2d6dd..b8dc99f7a1 100644 --- a/exploration/error-handling.md +++ b/exploration/error-handling.md @@ -56,15 +56,37 @@ The additional constraint in ICU4C's C++ style to return an error code rather th > 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.) +## Use Cases + +As a software developer, I want calls to message format to signal runtime errors +in a manner consistent with my programming language/environment. +I would like error signals to include diagnostic information that allows me to debug errors. + +As a software developer, I sometimes need to be able to emit a formatted message +even if a runtime error has occurred. + +As a software developer, I sometimes want to avoid "fatal" error signals, +such as might occur due to unconstrained inputs, +due to errors in translation of the message, +or other reasons outside the developer's control. +For example, in Java, throwing an Exception is a common means of signaling an error. +However, `java.text.NumberFormat` provide both throwing and non-throwing +`parse` methods to allow developers to avoid a "fatal" throw of `ParseException` +(if the exception were uncaught). + +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 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 MAY also provide the appropriate fallback representation of the _message_ defined -> in this specification. +> 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: @@ -80,6 +102,33 @@ This does not give implementations full freedom to return _nothing_ or some othe ## Alternatives Considered +### Separate Requirements + +The following spec text is proposed: + +> 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 ensures that even messages with runtime errors +can be formatted with the same string representation in all implementations. + +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. + +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. + ### Current spec: require information from error(s) and a representative best effort message The current spec text says: From dd20f3309db661c6d155e051d4ca7e5bd95df4b8 Mon Sep 17 00:00:00 2001 From: Elango Cheran Date: Mon, 29 Jul 2024 16:07:43 +0000 Subject: [PATCH 11/14] Apply suggestions from code review Co-authored-by: Richard Gibson --- exploration/error-handling.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/exploration/error-handling.md b/exploration/error-handling.md index b8dc99f7a1..35511ef056 100644 --- a/exploration/error-handling.md +++ b/exploration/error-handling.md @@ -58,7 +58,7 @@ The additional constraint in ICU4C's C++ style to return an error code rather th > returned, and "emit an error" is ambiguous as to what is or isn't performed.) ## Use Cases -As a software developer, I want calls to message format to signal runtime errors +As a software developer, I want message formatting calls to signal runtime errors in a manner consistent with my programming language/environment. I would like error signals to include diagnostic information that allows me to debug errors. @@ -67,8 +67,8 @@ even if a runtime error has occurred. As a software developer, I sometimes want to avoid "fatal" error signals, such as might occur due to unconstrained inputs, -due to errors in translation of the message, -or other reasons outside the developer's control. +errors in translation of the message, +or other reasons outside my control. For example, in Java, throwing an Exception is a common means of signaling an error. However, `java.text.NumberFormat` provide both throwing and non-throwing `parse` methods to allow developers to avoid a "fatal" throw of `ParseException` @@ -96,7 +96,7 @@ which can be accomplished in different ways. Ex: * 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 a global `boolean` values +and sets a global `boolean` value This does not give implementations full freedom to return _nothing_ or some other behavior. From aee2fb63fcd86359ca1d85632a5958f6e461c7aa Mon Sep 17 00:00:00 2001 From: Elango Cheran Date: Mon, 29 Jul 2024 09:29:22 -0700 Subject: [PATCH 12/14] Add ballot options from #830, designate selected design as such --- exploration/error-handling.md | 98 +++++++++++++---------------------- 1 file changed, 36 insertions(+), 62 deletions(-) diff --git a/exploration/error-handling.md b/exploration/error-handling.md index 35511ef056..2b4b9420df 100644 --- a/exploration/error-handling.md +++ b/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, From 1051cee1cd11112661f9060878ebc5db5f6de2ab Mon Sep 17 00:00:00 2001 From: Elango Cheran Date: Mon, 5 Aug 2024 09:19:05 -0700 Subject: [PATCH 13/14] Add meeting notes and ballot issues --- exploration/error-handling.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/exploration/error-handling.md b/exploration/error-handling.md index 2b4b9420df..1b78b0b4c3 100644 --- a/exploration/error-handling.md +++ b/exploration/error-handling.md @@ -11,8 +11,16 @@ Status: **Proposed**
2024-06-02
Issues
#782
+
#830
+
#831
Pull Requests
#795
+
Meeting Notes
+
2024-05-06
+
2024-05-13
+
2024-05-20
+
2024-07-15
+
2024-07-22
From 084a1de541be0947be3b89d81037da7e5368d9f6 Mon Sep 17 00:00:00 2001 From: Elango Cheran Date: Mon, 5 Aug 2024 16:19:30 +0000 Subject: [PATCH 14/14] Apply suggestions from code review Co-authored-by: Eemeli Aro --- exploration/error-handling.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/exploration/error-handling.md b/exploration/error-handling.md index 1b78b0b4c3..82a412a176 100644 --- a/exploration/error-handling.md +++ b/exploration/error-handling.md @@ -1,6 +1,6 @@ # Error Handling -Status: **Proposed** +Status: **Accepted**
Metadata @@ -15,6 +15,7 @@ Status: **Proposed**
#831
Pull Requests
#795
+
#804
Meeting Notes
2024-05-06
2024-05-13