<@UGPMTH1D5> <@UE3D4UE15> If `objectMapper.convert...

# arrow

[raulraja]

@Derek Berner @Bob Glamm If objectMapper.convertValue can fail with an exception then it should be suspended and you should be using IO instead of Try. Try is going away or going to be modified because it can’t suspend effects or run suspend functions. If we make Try support suspend then we have IO.
On a different token you can encode internally all your error handling efforts including validation without implying fail fast or error accumulation and then export a la carte in your public API the error strategies for each data type that you want to support.
This link supports with the same code both fail fast and error accumulation https://arrow-kt.io/docs/patterns/error_handling/#example--alternative-validation-strategies-using-applicativeerror

[Derek Berner]

Hey, objectMapper.convertValue is a 3rd party library

[Derek Berner]

It can be wrapped in withContext(<http://Dispatchers.IO|Dispatchers.IO>) but cannot be directly suspended

[Derek Berner]

And it neither blocks nor suspends

[Bob Glamm]

If that's Jackson shouldn't that be IO { objectMapper.convertValue(...) } anyway?

[Bob Glamm]

since I think convertValue can throw an exception

[raulraja]

Yes, even if it's not suspended if it throws exceptions should be inside a suspend function or IO

[Derek Berner]

But... then I lose the ability to accumulate errors because IO is always fail-fast

[Derek Berner]

I'm not seeing from the link above how to make that work with IO, because IO is of type ApplicativeError<ForIO, Throwable>

[Bob Glamm]

As far as accumulating errors go, don't you have two modalities? assert(args.size == 3) must fail fast in order for the subsequent objectMapper.convertValue() methods to properly execute

[Bob Glamm]

but then you want objectMapper.convertValue() to all execute?

[Derek Berner]

I suppose that's true, the other 3 depend on the successful execution of the first

[Derek Berner]

But if it's >3, then they should still execute, to be "nice" to the RPC client

[Bob Glamm]

That just changes the condition in the assert rather than the modalities

[Derek Berner]

Regardless. Even if the first one cannot execute in parallel with the rest, the rest should still execute in parallel and accumulate, so the caller can fix all their errors at once

[Bob Glamm]

oh, so if args.size == 2 then also accumulate any errors from the first two `objectMapper.convertValue()`s?

[Derek Berner]

yeah, and if args.size == 3 then accumulate errors from all 3, etc

[Derek Berner]

I'm seeing that the first one should probably use a flatMap

[Bob Glamm]

I think I would wind arguments through Option or flatMap Validated instead of the first one

[Bob Glamm]

Maybe IO.traverse() over the validation conditions?

[Derek Berner]

But traverse isn't polymorphic

[Derek Berner]

a, b, and c are of generic types A, B, and C

[Derek Berner]

hence the use of Applicative

[Bob Glamm]

ahh, right, you'd be shoehorning types

[Derek Berner]

traverse exchanges polymorphism for variadicity (is that even the right term??)

[Bob Glamm]

my wild guess is that HLists would be most useful to you, except those don't exist in Kotlin

[Derek Berner]

I could create a shortcut type ValidatedIO<E: Semigroup<E>, Z> = IO<Validated<E,Z>>

[Derek Berner]

Then make it implement ApplicativeError<F, E>

[Derek Berner]

Which would require importing the optional kapt libraries

[Bob Glamm]

If you want * why not just use ApplicativeError<Any, Nel<Throwable>>?

[Bob Glamm]

if you truly don't care about the error type

[Derek Berner]

Sorry, I don't mean the Kotlin wildcard. I mean the type constructor ForXXX that Arrow implements through annotation processing magic

[Bob Glamm]

(maybe that's a dumb question; my memory of the original example is foggy)

[Derek Berner]

The first type arg for ApplicativeError is a type constructor that represents the functor type being used

[Derek Berner]

Not an error type

[raulraja]

@Bob Glamm there is HList in Arrow generic but there is no automatic type level derivation at compile time.

[raulraja]

@Derek Berner I’ll take a look at your example. Are you attempting to collect errors from operations that may fail?

[Derek Berner]

Yes

[raulraja]

I’ll play with it and see if I can come up with something, will post here when ready

[Derek Berner]

objectMapper is a JSON parser - this is happening near the point of the HTTP request handler

[raulraja]

so you are already in IO at that point?

[Derek Berner]

Kind of. It's in a suspend fun

[raulraja]

ok so yeah

[Derek Berner]

And it has a PipelineContext receiver which extends CoroutineScope

[Derek Berner]

If Validated had a monad transformer ValidatedT I could work with that

[raulraja]

yeah I see what you mean but there should be an alternative way with IO and the Concurrent hierarchy. Is objectMapper thread safe?

[Derek Berner]

According to stackoverflow, yes

[raulraja]

cool

[raulraja]

while I was working in your example https://youtrack.jetbrains.com/issue/KT-31664?project=kt

[Derek Berner]

😞

[Derek Berner]

I've crashed the IntelliJ compiler with Kotlin type args, too