You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
This is work that can be done incrementally, so perhaps this should be an epic, but for now, a list.
error
with structured types andimpureThrow
.The structured types will need a manual
Show
instance that builds the previouserror
message, so the resulting output is the same. And they'll need an emptyException
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, usingEither
(orValidation
) to get them to that point. This should also replaceimpureThrow
withthrowIO
when possible.replace calls to
impureThrow
withthrowAsException
(andthrowIO
withthrowIOAsException
), eliminating the manualShow
andException
instances that were created in step 1, moving theshow
definitions into standalonea -> String
functions near the throw site.This last step might require other changes to the frontend, because
AsException
may be hard toHasRep
, which is why this is separate from the other steps. We can address this separately and maybe simplify the steps here.The text was updated successfully, but these errors were encountered: