Moving the discussion from this thread <https://ko...
# arrow-contributors
Moving the discussion from this thread over here
I'm having a bit of a look this morning at my typical use case to see whether the discussed
function would help. I think there's a handful of functions that will need to be added, not just one
This is a typical example of how I'm parsing remote data using Either. Rather than short circuiting with GraphQL errors like we currently do. We'd like to change this to an Ior to track non-critical errors alongside the actual parsed data.
is a custom DSL function that raises if the error list is not null and not empty. We'd like to change this to a construct that accumulates errors rather than short-circuiting. It doesn't seem like there is a way within
to simply append/combine an error (since
is internal). We also filter out any list items that fail to parse with
mapNotNull { it.getOrNull() }
, it would be good to filter them out but also accumulate the errors.
I'm not sure that
Either<Error, A>.getOrAccumulate()
will be enough. There's currently an
Either<A, B>.toIor()
function that will never produce an
case. I wonder if an alternative like
Either<A, B>.recoverToIor(recover: (A) -> B)
function might help there?
With that the use case for filtering the list of parsing results might start to look like:
Copy code
.mapNotNull { it.recoverToIor { null }.bind() }
Not sure if this is the right direction though. Would be good to get some input on all of this
Would it make sense to open up
to be called inside the
ior {}