New Issue: Errors Module: 'DecodeError'and 'CodepointSplittingError'

jeremiah-corrado2 · November 21, 2022, 5:32pm

21069, "jeremiah-corrado", "Errors Module: 'DecodeError'and 'CodepointSplittingError'", "2022-11-21T17:31:50Z"

github.com/chapel-lang/chapel

Errors Module: `DecodeError`and `CodepointSplittingError`

opened 05:31PM - 21 Nov 22 UTC

closed 03:42PM - 03 Aug 23 UTC

jeremiah-corrado

type: Stabilization

### Background: The `DecodeError` and `CodepointSplittingError` types both li…ve in the `Errors` module and pertain to runtime errors with strings. - `DecodeError`is thrown when attempting to construct a `string` using non-utf8 characters - `CodepointSplittingError` is thrown when attempting to slice a string along a byte-boundary that is not a codepoint boundary ### Suggestions/Questions: - Should these be moved somewhere else in the standard modules? (This was discussed in the module review, and it sounds like people are leaning against moving them). - The other `Error` subclasses in the Errors module feel pretty fundamental to the language, while these are specific to the `string` type - If they do move, where should they be located? - Do we want to be more hierarchical and create a parent class for these? Maybe called `StringError`? - Are the current names okay?

Background:

The DecodeError and CodepointSplittingError types both live in the Errors module and pertain to runtime errors with strings.

DecodeErroris thrown when attempting to construct a string using non-utf8 characters
CodepointSplittingError is thrown when attempting to slice a string along a byte-boundary that is not a codepoint boundary

Suggestions/Questions:

Should these be moved somewhere else in the standard modules? (This was discussed in the module review, and it sounds like people are leaning against moving them).
- The other Error subclasses in the Errors module feel pretty fundamental to the language, while these are specific to the string type
- If they do move, where should they be located?
Do we want to be more hierarchical and create a parent class for these? Maybe called StringError?
Are the current names okay?