How to represent many subsets of an enum?

Thanks for the explanation - where do these terms come from? Scala? Haskell? ReasonML? The term OutMsg is the only one I have heard of in the Elm realm previously. In Elm we sometimes talk about the out message pattern, where you have an update function that may return an additional value:

update : Msg -> Model -> (Model, Cmd Msg, OutMsg)

-- Or
update : Msg -> Model -> (Model, Cmd Msg, Maybe OutMsg)

Where the out message tells the caller about some event of interest, such as a state change in this module instance. For example, I use it in my auth module to inform the caller when the auth state changes from LoggedOut to LoggedIn and so on.

Interestingly for me, the Translator pattern is what I used in my code generator. Each code generator module has its own error type. I also defined a common error type, which consists of a String and an error code. The errors in this case are very similar to compiler errors - they are aimed at being descriptive and helpful to the user to solve a problem with their code, and there can be more than one of them. The error code is unique to each type of error, and is also used as a key into an error catalogue. The error catalogue is a site I built with elm-pages, it has a section for each kind of error that gives more detailed background on the error, examples of the error, issues around it, how to fix it, that sort of thing. The idea is that in the UI I can link off to the error catalogue for more detailed context sensitive help.

I touched on some of these ideas here:

And got a package out of it for results with multiple errors:
https://package.elm-lang.org/packages/the-sett/elm-error-handling/latest/

For that project, having one error type per module worked out pretty well. Also I always handle all errors in the same way, and each code gen module provides the same function to convert into the common format, so its pretty easy to hook everything together. For these AWS API stubs, having one error type for each endpoint would feel like too much, given that there are tens to a hundred endpoints in each module. That said, it is generated code so creating lots of boilerplate isn’t an issue. I’m more thinking it will be a pain for the user of the API to wade through such a bloated interface.

I quite like the Translator pattern though - either you deal with an error right away, or else you translate it into a less specific form and pass it up. Often a String that you can log is good enough. The errors that you don’t deal with can usually be either thought of as runtime errors that signify a bug in your code, or unrecoverable system errors like a 500 response from some service - you just want to do your best to log the string for the attention of the technical team.