Service implementations expose different errors; do I expose or wrap errors, or do something else?
effect✅Solved!
https://effect.website/play/#30ac3a651af6
I have an auth token service. I have one implementation that won't throw expected errors and another where there are errors. If I define the "interface" in Context.Tag without a specific error, then the errors don't propagate through. If I explicitly define Error, it overrides the specific errors.
I suppose one option is to catch and wrap any potential errors as a custom error, like TokenError. Or maybe I can just discriminate through tags. That doesn't seem ideal. What's the most elegant and idiomatic way to design this?
I have an auth token service. I have one implementation that won't throw expected errors and another where there are errors. If I define the "interface" in Context.Tag without a specific error, then the errors don't propagate through. If I explicitly define Error, it overrides the specific errors.
I suppose one option is to catch and wrap any potential errors as a custom error, like TokenError. Or maybe I can just discriminate through tags. That doesn't seem ideal. What's the most elegant and idiomatic way to design this?
Effect Documentation
Similar Threads
Was this page helpful?
