Is there any project out there to do explicit error handling in Kotlin ? I'm thinking of something similar to std::expected (as explained here: https://bell0bytes.eu/expected/). I've read a little bit about Try<T> in Arrow but IMO it's a little bit too much tied to functional programming and requires some knowledge of the Arrow library. I think that Kotlin could benefit from a small, simpler Try<T> class and one or two syntactic sugar allowed by a compiler plugin. I'm thinking for instance of unwrapping a Try<T> variable using the !! operator, or implicit conversion of any object of type T to Try<T> when returning a value.

There is a plan for Result monad (actually almost the same as Try). If you need synthetic sugar from the language than it should be some proposal on Kotlin KEEP, or just write some draft and share to #language-proposals

Thanks for you input! Maybe the choice of the !! operator for unwrapping is not the best, it was just a first idea. A syntactic sugar would just allow people to use Try cleanly in an imperative way, which has a lot of advantages compared to the functional approach (this is why suspending functions are so great, much easier to use and read code compared to Future/Deferred/Publisher/etc). There are few advantages over unchecked exceptions, for instance you explicitly have to handle the exception/propagate it, and you can easily share the Try value returned by a function in a thread with another thread, which makes writing libraries much easier (in that case they don't have to handle the special case where an exception occurred in user code). We use this exact kind of error handling internally at Google in C++ and it has been proved for many years to be the best way of managing errors. I will make a proposal when I find the time this week to have the opinion of the JetBrains team :)

What is big difference between

try.getUnsafe()

and

try!!

?

You could use try ?: defaultValue or try ?: throw MyCustomException() in those cases 🙂 Looks nice to me.

what if try is nullable?

It doesn't clash, the operation would apply in the right order. If you have a Try<T>?, the first !! would return Try<T> or throw a NullPointerException. Then a second !! would unwrap T or make the function return a failure. If you have a Try<T?>, the order would be the other way around 🙂

I suppose before do proposal would be better to share your thoughts about language support and use cases in this task https://youtrack.jetbrains.com/issue/KT-18608

try?.operationThatOnlyWorksOnTryString

So nullableTry just unwrapped to non-nullable String?

in that case you could use try?.flatMap { it?.length } and you would get a Try<Int?>?

At least syntax with functions doesn’t have this clash of operators. In case of

Try<String?>?

you have 3 different states: non-nullable String in Success nullable String in Success Failure And it’s easy to imagine cases when you want to distinguish all of them

But I would argue that this would never happen, methods should never return a nullable Try

Why?

How often do you encounters methods that return a nullable Future? 😉

But try is not a future

I know, but the concept is the same. It's a monad

In case of

Try<String?>?

you have 3 4 different states: non-nullable String in Success nullable String in Success Failure Null

As I said, if the operator is a problem, we could use something different 🙂

In general I like your idea. I just think that it never be implemented because of many edge cases. If we talking about another operator

If the Kotlin team decides to introduce Monads one day I wouldn't be surprised that they use those operator as sugars

But you do realize that the ?. operator has the same semantics as flatMap right?

Very similar, but you can nest monads (including Try), but you cannot nest nullable types

Thanks, I will do that later today when I'm back from work 🙂