Choosing how to wrap and represent errors when integrating `valibot` with `Effect` involves balan...

I'm wrapping

valibot

valibot

's unsafe

parse

parse

with

Effect

Effect

. For ref, it either returns parsed value on success OR throws a

ValiError

ValiError

on failure.

In the wrapped

Effect

Effect

version, would you expect the error channel to be:
1. The original

ValiError

ValiError

2. Different name
-

TaggedError

TaggedError

with a distinct name (

ValiEffectError

ValiEffectError

) and a

cause

cause

field set to the original error
3. Same name, cause field
-

TaggedError

TaggedError

of the same name (

ValiError

ValiError

) and a

cause

cause

field set to the original error
4. Drop-in replacement
-

TaggedError

TaggedError

of the same name (

ValiError

ValiError

) that extends the original

ValiError

ValiError

- if so, with or without a cause field?
5. Global override
- A

TaggedError

TaggedError

of the same name (

ValiError

ValiError

) that globally overrides the original error
- ie. via

declare module

declare module

I don't like 1 or 5, although

zod

zod

's effect plugin (which stumbling across was the inspo for a

valibot

valibot

eq) does do 5

In theory I like 3, but I'm finding it's more of an annoyance to have to go through

cause

cause

. It's an option to choose some key fields to also hoist. Which in that case, might as well be 4?

const newError = new ValiError({ cause: existing, issues: existing.issues });

const newError = new ValiError({ cause: existing, issues: existing.issues });

Curious what others think

Choosing how to wrap and represent errors when integrating `valibot` with `Effect` involves balan...

I'm wrapping

valibot

valibot

's unsafe

parse

parse

with

Effect

Effect

. For ref, it either returns parsed value on success OR throws a

ValiError

ValiError

on failure.

In the wrapped

Effect

Effect

version, would you expect the error channel to be:
1. The original

ValiError

ValiError

2. Different name
-

TaggedError

TaggedError

with a distinct name (

ValiEffectError

ValiEffectError

) and a

cause

cause

field set to the original error
3. Same name, cause field
-

TaggedError

TaggedError

of the same name (

ValiError

ValiError

) and a

cause

cause

field set to the original error
4. Drop-in replacement
-

TaggedError

TaggedError

of the same name (

ValiError

ValiError

) that extends the original

ValiError

ValiError

- if so, with or without a cause field?
5. Global override
- A

TaggedError

TaggedError

of the same name (

ValiError

ValiError

) that globally overrides the original error
- ie. via

declare module

declare module

I don't like 1 or 5, although

zod

zod

's effect plugin (which stumbling across was the inspo for a

valibot

valibot

eq) does do 5

In theory I like 3, but I'm finding it's more of an annoyance to have to go through

cause

cause

. It's an option to choose some key fields to also hoist. Which in that case, might as well be 4?

const newError = new ValiError({ cause: existing, issues: existing.issues });

const newError = new ValiError({ cause: existing, issues: existing.issues });

Curious what others think

Choosing how to wrap and represent errors when integrating `valibot` with `Effect` involves balan...

Similar Threads

Choosing how to wrap and represent errors when integrating `valibot` with `Effect` involves balan...

Similar Threads

Similar Threads

Similar Threads