Composable errors and type safety

[JacksonUtsch]

Here I am, a broken record. I'm looking for method to modularize error handling and have it be type safe. This is generally done with the Result type in Swift, as throws are untyped.

Why would we want type safe errors and for them to be modular? Exhaustive applications! Without such, how are we to handle unexpected error cases? Type safety allows us to understand potential errors and appropriately deal with each case as need be. We can even easily create user or developer facing associated messages.

With the new ReducerProtocol I considered the option of using the Result type as the Action. I thought it would work out better than it did. There are consequences of doing so, like having to handle error cases in each reducer rather than composing the reducers. It gets a little messy.

If Error types are opted into the ReducerProtocol type then composition can take place where errors can be propagated through feature domains and handled globally where some or most errors can't be handled locally in their feature domain.

Here is my brief testing with from protocol branch

Episode 196 talks about the error situation some

[JacksonUtsch]

If this direction is not taken, what are we supposed to do with global errors that we want to present the user? These are unable to be propagated from features.

[stephencelis]

@JacksonUtsch I mentioned it in a reply to your other recent comment about error handling, but I think concrete demonstrations are necessary to help sell and better explain your points, and/or help us find alternate solutions. Wanna sketch out a working case study or two that captures the problem at hand and potential solutions?

[JacksonUtsch]

@stephencelis Agreed. I'm finding it quite difficult to make all the changes necessary for the library itself with the intricacies of task execution and while supporting Publisher. Would an independent project be suitable for demonstration or perhaps if you have a suggestion?

[JacksonUtsch]

@stephencelis With some experimenting it seems Action can be used to adopt a failure case. This does change the behavior of streams continuing to execute but ultimately this may be preferred. So no changes are needed with this method! Thank you for entertaining the idea, I may create a case study for insight on the use case.

[JacksonUtsch]

Here is a case study I made that demonstrates the idea and some use cases. +1 from me to add _Observe to TCA

[JacksonUtsch]

@stephencelis Not sure if you've been able to take a look. Does this method of propagating errors merit any validity?