Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OptionalUnit Rule on suspendCoroutine context #4363

Closed
panoramix360 opened this issue Dec 9, 2021 · 3 comments
Closed

OptionalUnit Rule on suspendCoroutine context #4363

panoramix360 opened this issue Dec 9, 2021 · 3 comments
Labels

Comments

@panoramix360
Copy link

panoramix360 commented Dec 9, 2021

Expected Behavior

Don't throw an issue for OptionalUnit when used with suspendCoroutines that return nothing

In the following code, I can't remove Unit from the return because suspendCoroutine needs to known the function return type.

override suspend fun doAction(): Unit = suspendCoroutine { cont ->
        Integration.signOut() {
            it.fold(
                {
                    cont.resume(Unit)
                },
                { error ->
                    cont.resumeWithException(error as Exception)
                }
            )
        }
    }

Observed Behavior

Detekt is complaining with a OptionalUnit rule.

Steps to Reproduce

  • Create a function that uses suspendCoroutine and returns nothing (Unit)

Context

Detekt is not passing in this particular case in my project.

Your Environment

  • Version of detekt used: 1.18.1
  • Version of Gradle used (if applicable): 7.0.3
  • Operating System and version: Ubuntu 18.04
@severn-everett
Copy link
Contributor

A workaround for this would be to specify the type in the generic bracket, e.g.

override suspend fun doAction() = suspendCoroutine<Unit> { cont ->
        Integration.signOut() {
            it.fold(
                {
                    cont.resume(Unit)
                },
                { error ->
                    cont.resumeWithException(error as Exception)
                }
            )
        }
    }

@panoramix360
Copy link
Author

panoramix360 commented Dec 13, 2021

Hi @severn-everett, it worked like you suggested!

But I think it's nice to address this on the other way around too.

Thank you for helping and opening a PR to adjust this.

@BraisGabin
Copy link
Member

Thanks for the report @panoramix360. Closing because @severn-everett fixed it in #4371

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants