Hei ! I can’t find the thread back, so I’ll ask ag...
# arrow
s
Hei ! I can’t find the thread back, so I’ll ask again. Why CancellationException is considered as Fatal error, and thus not being caught in Either.catch ? Since my operations inside bracketCase are wrapped in Either, I have to explicitly catch CancellationException, to rollback my transactions on ExitCase.Cancelled
s
Hey @Satyam Agarwal, Sounds like you want to write a higher-level function for your use case. Mind sharing some code, and your use case?
s
s
Ah, I see what you're trying to do. Give me a second, this code can be simplified a lot 🙂
@Satyam Agarwal I was able to simplify the code a lot, this has the same semantics. Can you check if this covers all your use-cases?
You can safely call
bind
from within
use
and there is no need to nest
Either.catch
inside
Resource#aquire
Slightly changed to showcase the separation of concerns better
s
Thats really nice. But the problem is :
Copy code
DbLib.useTxn { IllegalStateException().left() }
will not reach
ExitCase.Failure -> rollback()
and hence, nor, do
connection.close()
Therefore, I had to do the nested either, and throw explicitly. This works as expected:
Copy code
DbLib.useTxn { throw IllegalStateException() }
and to add to the problem, if we do
Copy code
DbLib.useTxn { throw CancellationException() }
then we will be thrown out of either.
s
That's why I used
bind
directly in
use
and that way it works the same as
throw IllegalStateException()
DbLib.useTxn { IllegalStateException().left() }
will reach
ExitCase.Failure -> rollback()
due to the
bind
inside of
useTxn
implementation
use { IllegalStateException().left().bind() }
will result in
ExitCase.Failure
DbLib.useTxn { throw CancellationException() }
this will result in
ExitCase.Cancelled
but in that case, it also rolls back, so not sure why that is an issue?
Similarly
DbLib.useTxn { Either.catch { throw CancellationException() } }
is equal to
DbLib.useTxn { throw CancellationException() }
so that will also result in
ExitCase.Cancelled
and a rollback
Does that not cover your use-cases?
s
😅 I understand that, but its not working the intended way. I have updated the gist with tests too. https://gist.github.com/satyamagarwal/e857ccad1c396e48b8330a80948baf49 Would you please take a look, and try to run them, last two tests should fail. second last test will fail on assertion, as the state expected is Closed, however, actual state is still open. and last test will fail because of either crashing.
s
Hey @Satyam Agarwal, Looked at your code and you're right. This is actually fixed in the latest Arrow (we're in process of reviewing the release post so will be released really soon). If you use
1.0.3-alpha.37
and
arrow.core.continuations.either
instead of
arrow.core.computations.either
then your tests will pass 🙂 Can you let me know if it worked for you? I tried it locally and everything is green for me.
My head is on the latest Arrow so ... sorry for confusion 😅
The new runtime includes some fixes and improvements so that everything composes more naturally without requiring hacks like you had before
👍 1
s
Ah. I Could've specified the version too, sorry. Awesome. I'll try to run this on the alpha and check it out. Oh? I'll check the api docs. Or I can just wait for the blogpost.
s
I wrote a couple of blogs about the new underlying runtime. Everything that was previously in
computations
is now powered by
Effect<E, A>
. https://nomisrev.github.io/ And there are more details in the Kdoc, https://github.com/arrow-kt/arrow/blob/main/arrow-libs/core/arrow-core/src/commonMain/kotlin/arrow/core/continuations/Effect.kt Probably easier to read in IntelliJ if you've pulled the alpha version, this will be on the main website after the version is released. The release post will not go very deep on these technical details. If you have any questions be sure to ask them here! 🙂
s
Awesome. Thank you so much for the help. I'll read through them by the weekend.
arrow 3
Just read the blog post about, and realized I read it as soon as you published it. Gave it a read to refresh my memory. Haven't pulled the alpha yet, but but using continuation.either, I am guessing either block now leverages effect under the hood ?
I'll check it out anyway. I think I am fairly caught up with the changes.
Thanks.
s
I am guessing either block now leverages effect under the hood ?
Yes, the either block implementation is now
effect(f).toEither()
😄
👍 1
You're very welcome @Satyam Agarwal! Thanks for all your support, and feedback to Arrow 🙌
❤️ 1