is anyone using the Result monad in production?

# announcements

[ursus]

is anyone using the Result monad in production?

[kevinherron]

i'll use one in prod once it's part of Kotlin stdlib. I suspect they'll do something fancy with an inline Result in 1.4

[kevinherron]

or, I hope they will.

[gildor]

Result already inline

[ghedeon]

wondering, where do you plan to use it. And it probably changes the error handling approach, right?

[ursus]

well I noticed .runCatching. which wraps the reusilt or catches the exception

[ursus]

im still kind of unsure as how to do error handlng, since checked exceptions are gone, yet I need them in java interop

[ursus]

lets say retrofit call, I execute a request, get a response, check that for 200, -- else what? throw like BadRequestException? Mean while call site needs to handle IOException + Json parsing exceptions

[ursus]

so people say you shouldnt use exceptions to drive flow, so, in theory I should return Result from the api call, where the error is branch non 200 status code. And now another method which would wrap the check exceptions, and flatten out the error too -- im not so sure about how I feel about this + you ll need some logic to rethrow fatal exceptions

maybe like this?

fun ApiClient.whatever(): Result {
    try {
		val response = api.whatever()
		if (response.code != 200) {
		    return Result.Success(response.body)
		} else {
			return Result.Error(BadRequestError(code)
		}
	} catch(ex: IOException) {
		return Result.Error(IOError)
	} catch(ex: Exception) {
		throw ex
	}
}

[ghedeon]

I ended up throwing exceptions and using runCatching{} because I really like how you can have pure data in your stream in Rx for example, not mixed with errors, and I really hate to wrap it in Result like LiveData does, just because you have no other options. Idk... it's messed up. I clearly remember when everybody was hyped about rx .onError{} because separate error channel is a step forward from try/catch and now try/catch is being sold as something revolutionary, idiomatic and clean.

[ursus]

@ghedeon what? you confused me totally lol -- so you wrap your synchronous throwing functiosn with runCatching, thuss passing kotlin.Result into stream -- but that last part try catch being clean you lost me

[ghedeon]

maybe I wasn't clear enough, I just use it in official way: function returns data and throws ex in case of error. Caller side is using tryCatching{}. Nothing special. Beside, I was just speculating about Result pattern, not necessarily kotlin.Result, but in general.

[ursus]

okay but isnt that the point of Result, that the result type is explicit, and exceptions are now hidden? -- in my sample, youd not return Result, just the response.body and throw in case of non 200, and let the caller deal with it?

[ursus]

Does anyone know what Swift does?

[gildor]

In Swift all the exceptions are checked

[gildor]

im still kind of unsure as how to do error handlng, since checked exceptions are gone, yet I need them in java interop

But you have checked exception for Java interop, there is @Throws annotation for that

[ursus]

only in kotlin code it is, there nothing barring you from not handling it in okhttp.request.execute or whatever the api is

[gildor]

Yes, Kotlin code doesn't have checked exception and this is one of initial design goals of Kotlin to get rid of Java's checked exceptions