Is there a clean approach to declaring essentially...

# arrow

[Michael Friend]

Is there a clean approach to declaring essentially a union error type for functions to reduce redundancy/wrapping on more generic error types? Basically what i have is some HttpClient helper functions that use a sealed interface HttpClientError (UnsuccessfullResp, ResponseParse etc) to report more http related generic errors, and i have client classes for various apis that use these functions but want to basically add some more api specific errors like FilteringError to the signature of those client functions, to make the overall error type of these essentially HttpClientError | MyApiSpecificError (or maybe even more fine tuned if some end points have possible logic errors that others dont). Solutions Ive used in the past are this quick and dirty method of just doing interface HttpClientError: MyApiAError, MyApiBError but that obviously gets gross fast, or what i assume is the recommended approach of having MyApiError have a subclass that wraps any HttpClientError . Is the latter the most "functional idiomatic" approach or is there something that doesnt require writing code to wrap HttpClient error in every call?

[Michael Friend]

I am using context parameters with raise rather than raise as a receiver so there is also the option of doing context(_: HttpClientError, _: MyApiAError) but i find the api of dealing with multiple raise types a little clunky

[simon.vergauwen]

but i find the api of dealing with multiple raise types a little clunky

It's indeed a bit clunky since it requires n-nested recover to handle all n errors.

I hope that this will become obsolete, or redundant, with rich errors though 🤞

I think for now writing the additional code, or providing some utilities for them is the best way of dealing with them.

[Michael Friend]

Yea im super eager for rich error support its gonna really clean up a lot of stuff. In the mean time do usually find yourself using multiple raise context parameters and providing some helpers to handle both paths cleanly or do you more often use a wrapper class and just expose one error type? Im guessing since context params are so fresh and the multiple raise contexts isnt possible with raise receiver functions or in an Either type parameter a DomainError hierarchy with a wrapper is more common atm. Its definitely more backwards compatible

[simon.vergauwen]

Yes, having a hierarchy is very common. Ideally you split it up at boundaries, but it's a trade-off situation depending on the application.

I like helpers and context params, it unwrapping all types more clearly shows the domain which I really like

[Michael Friend]

Makes sense to me. I've been really enjoying raise with context params so far, ive been able to write some really clean helper functions with them. Ill have to impatiently wait for a rich error preview to be available i think thats the last piece needed to achieve a near perfect api for error handling