Problem
— I would open this as a discussion, but this repo has disabled discussions tab.
First, thank you so much for the effort you've put in this library. It looks great at a glance!
I wonder if the usage of TaggedError is a hard requirement for this lib to work well, or if it can be used with normal errors too. I ask this because we already use another solution for modelling domain errors, so depending on this library at this level is almost an adoption barrier. Nevethrow allows anything to be used in error paths, so I assume the role of TaggedError is to filter which errors are modeled and which are unexpected. To be clear, I'm just asking the design decision behind TaggedError.
Proposed solution
I think a better interoperability with the user's existing errors could greatly increase this library's adoption.
Alternatives considered
No response
Scope check
Problem
— I would open this as a discussion, but this repo has disabled discussions tab.
First, thank you so much for the effort you've put in this library. It looks great at a glance!
I wonder if the usage of
TaggedErroris a hard requirement for this lib to work well, or if it can be used with normal errors too. I ask this because we already use another solution for modelling domain errors, so depending on this library at this level is almost an adoption barrier. Nevethrow allows anything to be used in error paths, so I assume the role ofTaggedErroris to filter which errors are modeled and which are unexpected. To be clear, I'm just asking the design decision behindTaggedError.Proposed solution
I think a better interoperability with the user's existing errors could greatly increase this library's adoption.
Alternatives considered
No response
Scope check
CLAUDE.mdand this doesn't duplicate an existing concept or a deliberately-excluded one (generator do-notation, error accumulation, aliases, anOptiontype).