Hi, I have a data class named `Error` that I want ...

# getting-started

[Eivind]

Hi,
I have a data class named Error that I want to use to represents errors occuring in my api (not exceptions, but state different than what the user expected when they made their request). When I use it now Kotlin defaults to the java.lang.Error.

Can I change this default, or should I pick a different name?

[Minsoo Cheong]

@SinceKotlin("1.1") public actual typealias Error = java.lang.Error

this typealias exists in the kotlin stdlib TypeAliases.kt file
I think that picking a different name would be the easiest way, if keeping your class name isn't that important

[Eivind]

Yeah I changed it to ApiError. Not ideal, but close enough until something better. Thanks.

[Max Ferrier]

If you have more results class like your Error one, you can have a SealedClass Results with Error, success, etc.

[Eivind]

Yup I did initially have Success and Error in a sealed class Outcome, but I figured the vavr.io library has better support for all the functions I'd have to implement on my Outcome class anyway (fold, map, mapleft, flatmap etc), so I just started using that instead

[Ties]

@Eivind if you want to use FP in kotlin you might want to look at the Arrow library 🙂 (it is vavr but for kotlin)

[Ties]

It has an Either class for this exact purpose (also, shameless self promotion:

https://www.youtube.com/watch?v=Wojgv2MeMGU&t=80s▾

if you want to learn more about how to use this, it assumes no knowledge about eithers or that way of thinking)

[Eivind]

Thanks, that's neat 🙂 I've always used vavr for FP in Kotlin and Java. Would you say it's more idiomatic to Kotlin? Would I be better off using Arrow? Some of the code I work with is java and kotlin, so it isn't always pure kotlin code - does that matter?

[Ties]

It works a bit different depending on what you are using. In most ways Arrow is better than vavr because it integrates really well (because of kotlin features like extension functions and coroutines) in kotlin code. Collection wise standard kotlin might be better to use than vavrs collections, they are less optimal (since vavr uses linked list tricks underneath) but it gives the same 'convenience' of having map/flatmap etc without having to call .stream(). And you don't need to use collections from vavr (which have the same name as java.util collections and will probally cause confusion at some point).

The thing that sold me on Arrow was the either comprehension (like the for...yield from scala) which takes care of most flatMap magic when using eithers (the video will also show that bit)

[Ties]

Kotlin also has the Result type which is basically an Either but has a Throwable as a Left 🙂

[Ties]

(if this fits your use-case you don't even need a framework)

[Eivind]

I needed an either-esque container where I could have my own error type as the left. I fiddled with making one myself, but the monad type being available in vavr meant I didn't have to reinvent the wheel as far as fold, map, etc goes if I just used vavr 🙂 Because it's hard to tell if a throwable reveals too much information or not, so I'd rather replace the throwable with something I know will be safe to let bubble all the way up. But I'll check out arrow soon, that sounds nice (also never heard of the Optics data type??? what on earth.. 🤓)

[Ties]

The video will also explain Optics 🙂 (but thats a construction to make easy changes in deeply nested immutable data structures)