Design Patterns for Failure

I'm wondering if there is a good design pattern to follow that allows failures to be collapsed based on separation of concerns (for example, when implementing a service).

For example, when I implement

FooService

FooService

, it encounter specific errors such as

BarError

BarError

and

BazError

BazError

, which could be dependent on the specific implementation. From an interface perspective, it seems sensible to collapse these errors into a

FooError

FooError

(perhaps with semantics that are relevant to the

FooService

FooService

, e.g.

FooValidationError

FooValidationError

FooAuthError

FooAuthError

). In essence,

FooService

FooService

should only expose failure types that make sense, and not the implementation specifics.

At the moment I am creating a tagged error using

Data.TaggedError

Data.TaggedError

that contains a

cause: { _tag: string }

cause: { _tag: string }

field which carries the underlying failure (useful for debug purposes) which seems broad enough to capture all underlying known failures. I've not been able to find a specific type that represents failures, other than that they are tagged.

I'm encountering this issue when using AWS SDK (via @effect-aws) where the various clients can produce a number of failure types, but for the service that implements them, there isn't a reason to know about the specifics, rather the semantics such as whether the error is retry-able etc.

So when I make a client call, I have some sort of

.catch

.catch

which maps to the services more generic error type:

client.action(/*...*/).catchAll(cause => new FooError({ cause })

client.action(/*...*/).catchAll(cause => new FooError({ cause })

which allows the consumer of

FooService

FooService

to then catch on

FooError

FooError

tags, rather than the underlying implementation specific failure.

Design Patterns for Failure

FooService

FooService

, it encounter specific errors such as

BarError

BarError

and

BazError

BazError

, which could be dependent on the specific implementation. From an interface perspective, it seems sensible to collapse these errors into a

FooError

FooError

(perhaps with semantics that are relevant to the

FooService

FooService

, e.g.

FooValidationError

FooValidationError

FooAuthError

FooAuthError

). In essence,

FooService

FooService

should only expose failure types that make sense, and not the implementation specifics.

At the moment I am creating a tagged error using

Data.TaggedError

Data.TaggedError

that contains a

cause: { _tag: string }

cause: { _tag: string }

.catch

.catch

which maps to the services more generic error type:

client.action(/*...*/).catchAll(cause => new FooError({ cause })

client.action(/*...*/).catchAll(cause => new FooError({ cause })

which allows the consumer of

FooService

FooService

to then catch on

FooError

FooError

tags, rather than the underlying implementation specific failure.

Design Patterns for Failure

Similar Threads

Design Patterns for Failure

Similar Threads

Similar Threads

Similar Threads