How can I replace finally block in classic try { } catch ?

Finally exists because an uncaught exception returns from the enclosing scope.

Try { }

returns a value instead, you can act on the result of that value in any way you want.

close outputStream

Sounds like a case for Bracket . Closing a stream is an effect and Try can't suspend effects but IO can

It seems the documentation is not there yet. You can find it here https://github.com/arrow-kt/arrow/blob/38576f5ccee2b966eecf8ed36ddb5f4474190072/modules/effects/arrow-effects/src/main/kotlin/arrow/effects/typeclasses/Bracket.kt

I know I can do something like this with IO but how can I do it with Try ? in documentation is ForTry extensions but im not sure if its working in arrow 0.8.1

ForTry extensions

is deprecated in

0.8.1

but still available

You can use the same snippet but instead of using

ForTry extensions

you should be able to do `import arrow.instances.

try

.monad.*` or more specific `import arrow.instances.

try

.monad.binding`

Your code should still work without any other changes

The

fix()

is not required there anymore IIRC since we enable

bind()

on

Kind<ForTry, A>

directly instead of on

Try<A>

which means you don’t need

fix()

thx, but i can’t see

import arrow.instances.`try`.monad.*

is it in arrow-instances-core or arrow-instances-data ?

It’s in

arrow-instances-core

Hey all, if someone could take a look at this http://lordraydenmk.github.io//2018/functional-hangman-in-kotlin-with-arrow-part-2/ Just to make sure I am not saying something incorrect it would be great. Thanks and Merry Christmas

neat

I’m on it

first, change, in

-.pl

-.pl

good job 😄

you even added the extra step to use extfuns

What do you think of having

Option

in stdlib https://youtrack.jetbrains.com/issue/KT-29026 ?

I think that Kotlin has already gone the path of providing special syntax for nullable types and haaving an Option there may confuse people in when to use one vs another. What I would like to see in Kotlin is generalized treatment for all types that can flatMap so we can have proper do notation without the coroutine hack. As far as arrow goes we have contemplated in the past to export all

Option

ext functions and instances also to

?

so you can use the entire Option syntax and methods available in Arrow over

?

in the same way you can today over

Option

.

There is an isomorphism between

A?

and

Option<A>

and we can exploit that to enrich the

?

api with all the stuff that would be nice to have like

fold

,

map

,

mapN

, etc.

I wouldn’t split the semantics of null and undefined. It’s already a PITA in JS as it is lol

I think it's literally about having optional and nullable types. E.g. take Discord API - they say in documentation that some fields might be absent - they are optional - some might come null, whatever their type is - they are nullable - and some can be both.

I actually tried to emulate this behaviour with inline classes, but got stuck because Kotlin Serialization doesn't really tolerate them

@pakoito Yeah… very true! I was just thinking about my JVM world… 🙂

that’s an API design failure, where absence is used to represent semantics

and null is also used to represent semantics too

and both are different