Stylish safe way to check for nullability of multiple values with Detekt

Question

I'm using Danger Detekt (static code quality measurement system based on ktlint). I've got a function that fetches data from 8 different endpoints. Then I need to check if these values are not null and if so I return complex data type built with these values, but if any of these values is null I have to return null. Let's say it looks like this:

val first = endpoint.get()
...

then I could check it with complex if statement, but Detekt will complain about complex condition. So I changed it to this:

val first = endpoint.get() ?: return null
...

But Detekt is now complaining about too many return statements since I have to add it to every fetch.

Is there any handy Kotlin function for such problem?

Answer 1

You could use a fold to collect the results of each get, but make the accumulator null as soon as you hit a null result (and check that before you attempt each get call). So it latches into a failed state:

typealias Result = String

data class Endpoint(val name: String, val result: Result?) {
    fun get(): Result? {
        println("Getting endpoint $name - result is $result")
        return result
    }
}

val endpoint1 = Endpoint("One", "Result 1")
val endpoint2 = Endpoint("Two", null)
val endpoint3 = Endpoint("Three", "Result 3")
val endpoints = listOf(endpoint1, endpoint2, endpoint3)

// I heard yr linter hates returns
fun resultCollector(results: List<Result>?, endpoint: Endpoint) = 
    results?.run {
        endpoint.get()?.let { results.plus(it) }
    }

fun main() {   
    endpoints.fold(emptyList<Result>(), ::resultCollector)
}

>> Getting endpoint One - result is Result 1
   Getting endpoint Two - result is null
   (end)

You could use a lambda instead of a function reference but I just wanted it to be clear - you pass a result list through the folder, and the function does a couple of null checks (checks the results list, checks the result of the get call). Both of those checks can evaluate to null, and that's what the function will return as the next accumulator - the endpoint code is only executed (and an actual Result returned) if you don't hit a null

Personally I think that level of explanation means that maybe just a few early returns is much easier to follow and probably looks a whole lot neater when they're lined up too. Up to you though!