Seeking Idiomatic Ways to Re-expose Errors in Services
is there a more idiomatic way of re-exposing errors (i.e. in a service) to avoid 'leaking' errors similar to not leaking dependencies? I ended up with Effect.mapError and a instanceof check, but doesn't feel like the best way?
Production-grade applications in TypeScript.
6,221Members
Resources
Recent Announcements
Similar Threads
Was this page helpful?
