I'm getting a strange Sonar error that might be re...

# arrow

[David Kubecka]

I'm getting a strange Sonar error that might be related to my usage of Arrow RaiseDSL (which I believe is using coroutines under the hood). It might very well be possible, though, that this is simply a bug on the Sonar side. So I would like to ask you first if you see anything suspicious with the following code. If not I will treat the Sonar error as a bug and ignore it.

fun <R, E : ApiError> withApiError(block: Raise<E>.() -> R): R = recover(block) { error -> error(error) }

context(Raise<ApiError>)
fun <T> withAccount(productHashedId: String, block: Account.() -> T): T = TODO()

fun main() =
  withApiError {
    withAccount {
       withApiError { // simplified example - it's not clear why I need this but it doesn't matter here
          // do something with Raise<ApiError> and Account contexts
       }
    }
  }

Sonar is complaining about Unused coroutines Flow on this snippet. Does it make any sense? I'm not explicitly using coroutines in my code.

Here's a description of the relevant Sonar check: https://rules.sonarsource.com/kotlin/RSPEC-6314/

[Riccardo Cardin]

Which version of Arrow do you use?

[Riccardo Cardin]

By the way, the Raise DSL doesn’t use coroutines under the hood. It uses plain old local exceptions handling

[Riccardo Cardin]

Maybe the withAccount does something subtle?

[David Kubecka]

@Riccardo Cardin No, it does not 🤷

context(Raise<ApiError>)
fun <T> withAccount(accountId: String, block: Account.() -> T): T =
    with(repo.getByProductHashedId(accountId), block)

If there are no coroutines in the Raise DSL then Sonar really just got super confused 😄

[Riccardo Cardin]

Sorry, does the `repo.getByProduct`… use coroutines?

[David Kubecka]

nope

[Riccardo Cardin]

So, is it a blocking repository?

[David Kubecka]

Yes, normal JpaRepository

[Riccardo Cardin]

🤷‍♂️

[Riccardo Cardin]

Arrow version?

[David Kubecka]

1.2.4

[David Kubecka]

Never mind. Strange that it might sounds I really think that Sonar gets confused about something and that might not even be related to Arrow. Hard to tell...

[David Kubecka]

I've realized that Arrow uses the CancellationException alias which is in the kotlin.coroutines.cancellation package. So perhaps here is a tiny connection to coroutines which might have confused sonar.

[Riccardo Cardin]

Yep. The catch in the fold function is transparent to the CancellationException

[David Kubecka]

I don't think that's an accurate description. The way I read it is the RaiseCancellationException (which extends CancellationException ) is actually used as the main short-circuiting mechanism in the RaiseDSL. Moreover, I don't see any immediate reason why RaiseCancellationException extends CancellationException in the first place. Perhaps it's needed in other parts of the DSL but not in the central fold function.