mapErrors vs flatMapErrors

[ivan-kleshnin]

mapErrors maps error to a new error flatMapErrors maps error to a stream of values

I find this very counter-intuitive. Why it's made like that?

My expectation was to have both converting errors to values. I see little value in converting errors to another errors because errors are mostly new Error objects i.e. instances (prototype is important and immutable x -> y-like transformations aren't possible in general).

[rpominov]

The general idea of error related methods is to be symmetrical to similar value related methods. E.g.

• mapErrors is the same as map but for errors,
• skipErrors is the same as skip but for errors, etc.

Hopefully, this makes API more intuitive, once you get that idea.

[ivan-kleshnin]

I think I get the idea but what does "for errors" mean. It may mean two things:

1) error -> error2 (like basic map, but for errors)
2) error -> value (like catch in other stream libs)

mapErrors maps errors to errors (1) flatMapErrors maps errors to values (2)

It's not symmetrical to value related methods where both map and flatMap map values to values and the difference is just in type of return value. Types and API are symmetrical yes, but I-O channels aren't.

The behavior 2) is more important and I expected mapErrors to be like:

---e1---e2---| errors are 
---v1---v2---| converted to values

and not like

---e1---e1---| errors are 
---e1`--e2`--| converted to other errors

That's how flatMapErrors behave right now, so I have to use it where mapErrors would suffice.

[rpominov]

"error -> error2" this one.

flatMapErrors maps errors to values

flatMap and flatMapErros can do both:

// values -> values
s.flatMap(x => Kefir.constant(x))

// values -> errors
s.flatMap(x => Kefir.constantError(x))

// errors -> values
s.flatMapError(x => Kefir.constant(x))

// errors -> errors
s.flatMapError(x => Kefir.constantError(x))

[ivan-kleshnin]

Ouch. Now it makes sense to me. Closing...