I was watching the <Error Handling Strategies> tal...

# random

[dephinera]

I was watching the

Error Handling Strategies▾

talk from KotlinConf 2019 and they mentioned the approach I’m currently trying to apply in our project - using algebraic data types to represent the result which could be either a successful result type or an error. They also mention that when following this approach, one would either have a big error class hierarchy and therefore losing the type-checking and the exhaustiveness of handling the error, or you could have small error hierarchies based on the domain. My question is what do you do if the result you need is a combination of two or more domains, each of which has different errors that may occur? How do you define your error types in larger projects? Union types would come very in handy here, but I expect we won’t see them in the near future.

P.s: any materials on the topic (books, articles) would be much appreciated

[George]

I would represent it again as another sealed class. Happened to me a while back and it worked fine.