How to preserve the original error information whem mapping them?

[diogob]

We usually transform errors in composables using mapError.
I see a very common pattern:

const composableWithMorePreciseError = mapErrors(
  composableWithGenericError, 
  (errors) => [...errors, new MySpecificError()]
)

The goal above is not so much to transform an error, but to add some additional context or pre-processing before sending the errors elsewhere.

The problem

It is very common for developers to skip the spread, and remove existing errors from the list when doing the above. So the code above would be naively written as:

const composableWithMorePreciseError = mapErrors(
  composableWithGenericError, 
  (errors) => [new MySpecificError()]
)

Which is also an implementation I have seen in the wild. And hiding these details, despite looking like a good idea, hinder troubleshooting after the fact as it is very hard to know what we will need to debug a live system.

Perhaps we should create an incentive, in our API, for preserving the original errors.

A possible solution

A new combinator such as appendErrors : (errors: Error[]) => Error[].

This combinator, has the same signature as mapError but it just appends the errors returned to the original list. So we could write the simpler version of the examples above and still keep the full error history:

const composableWithMorePreciseError = appendErrors(
  composableWithGenericError, 
  (errors) => [new MySpecificError()]
)

[diogob]

@gustavoguichard @danielweinmann opinions?

[diogob]

I agree that it is simple enough to delegate to users (and perhaps have in some recipes section of the docs). However, I still wonder if nudging the user towards good patterns wouldn't warrant an out of the box combinator.

[diogob]

You see, I'm not really concerned with the developer that masters composables and is willing to write a custom combinator. This idea is geared towards the (potentially newbie dev) newcomer to the library.

[danielweinmann]

I think a newcomer wouldn't see the future benefit of using appendErrors and would probably choose mapErrors because the name is closer to what they are looking for. I never came across this use case also. Maybe let's try documenting mapErrors better before adding a new combinator?

[danielweinmann]

BTW @diogob, I see you used mapError in your example. I'm only familiar with mapErrors. Was it a typo?

[diogob]

typo fixed

[diogob]

I'll close this, documentation seems to be the way to go