What's the general consensus on the best way to have a function that can fail in multiple different ...

# announcements

[Jamie Taylor]

What's the general consensus on the best way to have a function that can fail in multiple different ways in Kotlin? I always thought we should use Result for that but just found out that it can't be the return type of a function. Should we just keep on throwing exceptions?

[Chantry Cargill]

sealed classes are the way to go.

[Stefan Beyer]

why cant it be in the return type?

[Chantry Cargill]

It’s experimental ^

[Jamie Taylor]

so do people normally make a sealed class for generic result types for each project they do, or make a separate sealed result type for each different type of result or what?

[Jamie Taylor]

it seems like having a standard one that provides functions like map and flatmap would be useful

[Sam Garfinkel]

sealed class Result

data class Result1(): Result

data class Result2(): Result

etc.

[Chantry Cargill]

That’s a matter of style. You can easily create a general Result type, but it’s also a fair pattern to have multiple types under a sealed class specific to your use case.

[Sam Garfinkel]

Monads are a good solution here

[Stefan Beyer]

When I just need this in very few places in a project, I usually use own sealed classes. But if it is a common theme, using libraries like Arrow would make sense 🙂

[Sam Garfinkel]

With the sealed classes you can define two results, one that returns Exceptionally (fails) and one that Succeeds with a val value: Any

[Sam Garfinkel]

sealed class Result

data class ExceptionalResult(val exception: Throwable): Result

data class Success(val result: Any?): Result

[Chantry Cargill]

If you do go down the Arrow route, https://arrow-kt.io/docs/0.10/apidocs/arrow-core-data/arrow.core/-either/.

[Jamie Taylor]

Lots of sensible options, thanks

[Jamie Taylor]

If you were starting a new project and needed a result type, is there any particular one you'd be more likely to go for?

[Chantry Cargill]

I personally write my own, but as I say, it’s a matter of style.

[Stefan Beyer]

and if you are writing a general solution yourself, dont use Any 😄

sealed class Result<T> {
    data class Success<T>(val value: T) : Result<T>()
    class ExpectedError<T>(val somethingThatHelpsToRecover: SomeType) : Result<T>()
    class UnexpectedError<T>(val errorMessage: String) : Result<T>()
    // ...
}

I also had some instances where I had several kinds of outcome, as well as several kinds of errors. at this stage, this whole thing becomes very funny ^^

[Stefan Beyer]

If you were starting a new project and needed a result type, is there any particular one you'd be more likely to go for?

my personal opinion is:
• try to avoid writing generalized (generic) result types. (because they get ugly really quickly)
• if you are not comfortable writing a sealed class for every case, then use a library like arrow. (10 sealed classes may be ok, 1000 is just ridiculous)