This is work that can be done incrementally, so perhaps this should be an epic, but for now, a list.
- replace any uses of
error with structured types and impureThrow (see https://gerrit.heavisoft.kittyhawk.aero/c/heavisoft/+/13613 for first steps here)
The structured types will need a manual Show instance that builds the previous error message, so the resulting output is the same. And they'll need an empty Exception instance so they can be thrown.
This is the first step that has a few benefits
we get away from strings (concatenation of which does not play well with the controller frontend)
we have structured failures that constrain what can go wrongbut it also has some shortcomings relative to the goal
serialization is still defined alongside the data type, rather than closer to the user
the types still don't indicate failure
-
push the calls to impureThrow down the call stack as far as possible, using Either (or Validation) to get them to that point. This should also replace impureThrow with throwIO when possible.
-
replace calls to impureThrow with throwAsException (and throwIO with throwIOAsException), eliminating the manual Show and Exception instances that were created in step 1, moving the show definitions into standalone a -> String functions near the throw site.
This last step might require other changes to the frontend, because AsException may be hard to HasRep, which is why this is separate from the other steps. We can address this separately and maybe simplify the steps here.
(Extricated from https://kitty-hawk.atlassian.net/browse/SW-2658)
This is work that can be done incrementally, so perhaps this should be an epic, but for now, a list.
errorwith structured types andimpureThrow(see https://gerrit.heavisoft.kittyhawk.aero/c/heavisoft/+/13613 for first steps here)The structured types will need a manual
Showinstance that builds the previouserrormessage, so the resulting output is the same. And they'll need an emptyExceptioninstance so they can be thrown.This is the first step that has a few benefits
we get away from strings (concatenation of which does not play well with the controller frontend)
we have structured failures that constrain what can go wrongbut it also has some shortcomings relative to the goal
serialization is still defined alongside the data type, rather than closer to the user
the types still don't indicate failure
push the calls to
impureThrowdown the call stack as far as possible, usingEither(orValidation) to get them to that point. This should also replaceimpureThrowwiththrowIOwhen possible.replace calls to
impureThrowwiththrowAsException(andthrowIOwiththrowIOAsException), eliminating the manualShowandExceptioninstances that were created in step 1, moving theshowdefinitions into standalonea -> Stringfunctions near the throw site.This last step might require other changes to the frontend, because
AsExceptionmay be hard toHasRep, which is why this is separate from the other steps. We can address this separately and maybe simplify the steps here.(Extricated from https://kitty-hawk.atlassian.net/browse/SW-2658)