You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I really like the idea of type-safe errors but still struggle on how to correctly define them in interfaces.
Let's say I have the following interface for an AI prompt template with a create() and validate() method. Both of these may produce different errors so I added generic type parameters for TCreateError and TValidateError. While this works, it of course scales with the amount of methods and gets pretty unwieldy.
Am I doing this wrong? Should I define the errors upfront (Result<Prompt<TSettings, TData>, CreateError>)? I wanted to give implementing classes the option to define multiple "sub-errors" to provide more fine-grained errors as a union.
I really like the idea of type-safe errors but still struggle on how to correctly define them in interfaces.
Let's say I have the following interface for an AI prompt template with a
create()
andvalidate()
method. Both of these may produce different errors so I added generic type parameters forTCreateError
andTValidateError
. While this works, it of course scales with the amount of methods and gets pretty unwieldy.Am I doing this wrong? Should I define the errors upfront (
Result<Prompt<TSettings, TData>, CreateError>
)? I wanted to give implementing classes the option to define multiple "sub-errors" to provide more fine-grained errors as a union.The text was updated successfully, but these errors were encountered: