Heya, guys! I'm trying out the functional approach...

# arrow

[Trond Engell]

Heya, guys! I'm trying out the functional approach in my project with use of IO. In this case I am trying to guarantee that method log() is called if result is either failure or success. Only the following is being printed, though:

Failure

I would have expected Finalized to be printed also. Why is this not happening? Am I using raiseError in a way that was not intended? Any help is appreciated :)

raiseError() + guarantee()

[aballano]

Hi there! The code looks fine, can you tell me which version of Arrow are you using?

[Trond Engell]

0.10.4

[aballano]

ah, it seems that was a bug in that version, fixed in the next one https://github.com/arrow-kt/arrow/issues/1999

[aballano]

that’s fixed in the 0.10.5-SNAPSHOT version, which we’re close to release, so it should be safe to use IMO 🙂

[Trond Engell]

Ah. Thanks!

[aballano]

You’re welcome! Let us know if you have any questions

[Satyam Agarwal]

Out of curiosity, why guarantee is used in the fashion ? I would assume the only use case for guarantee would be for operations that need to close the resource regardless of the operation with resource was successful or not, basically bracket.
Just trying to understand whats the value of using gurantee here ?

[aballano]

what you described it’s indeed bracket, guarantee on the other hand doesn’t care about adquisition or use, but simply release, so it’s useful when you want to track how your program behaves for tracking/reporting, for example

[aballano]

https://next.arrow-kt.io/docs/fx/typeclasses/bracket/#bracket

[aballano]

there are also more specific functions like onCancel and onError as well

[Satyam Agarwal]

oh, sorry I didn’t ask properly. I was asking about the use of guarantee in this specific example, where its just a log line, and it doesn’t need to be .guarantee(log()). A simple flatmap{ log() } or followedBy(log()) will always get executed, right ? There is absolutely no way where this can fail in my head, so why to use gurantee here ? The reason why I am asking is, there could be other reasoning to use gurantee where working with resource is not the scenario. Thus so curious 🙂

[aballano]

Ah I see, no in any case that you have an error, no flatmaps will be run, because you are in an error state

[aballano]

you can imagine IO in this case somewhat like an Either (on steroids), you might have an error or a value, so flatmap and any other normal operator only work over the value, not on the error. For errors you can handleError to recover and then you can do your ops

[aballano]

does that help? 😄

[Satyam Agarwal]

Omg. I am terribly sorry for making this obvious mistake, I know that 😅 , I am so out of the zone today. I actually wanted to write this :

IO
    .raiseError<Unit>(RuntimeException("Blarg!"))
.handleError{_ -> log() }

so an alternative to this would be using guarantee instead of using handleError or handleErrorWith ?

[aballano]

hahah no prob. Yes, that would virtually be very similar to the above, the only difference is that with handleError the log will be executed on error, whilst for guarantee you’ll also execute it on completion and cancellation as well.

[Satyam Agarwal]

Right. I understand. Thanks a lot 🙂

[aballano]

no prob! 🙂