So, after upgrading to kotlin 1.7.10, the exhaustive when clause has kicked in. This has caused us ...

# getting-started

[mattinger]

So, after upgrading to kotlin 1.7.10, the exhaustive when clause has kicked in. This has caused us to have to add a lot of this type of block to our code in cases where we’re only interested in one or two cases of an enum:

SOME_VALUE_WE_DONT_CARE_ABOUT -> { }

The issue is that sonarqube is treating this as a code smell, and our quality gate is blocking merges when this happens. So we have to either change our quality gate, or use admin privs to merge. Does anyone know if there’s a way to tell sonar to ignore these?

[Klitos Kyriacou]

Isn't Sonar happy if you just put else -> {}?

[kenkyee]

else ->
{ /*intentionally skipped* / }

[mattinger]

@Klitos Kyriacou As an org, we don’t want an else block like that. The problem is that as new enum values are added, you are not forced to make a conscious decision whether you need to handle it or not. That was my original inclination to do that but after conferring with some of the other devs, we decided to be specific and use the “add missing cases” resolution in AS instead.

[Michael de Kaste]

unless the enums/sealeds are enormous, we manually put in all the other values
so if an enum consists of 5 values: enum class Count{ ONE, TWO, THREE, FOUR, FIVE }
and we only do something on even values:

when(count){ 
   TWO, FOUR -> doThing()
   ONE, THREE, FIVE -> { }
}

when we add SIX as a value, we get compile errors

[Michael de Kaste]

I guess thats the consensus for making your code future safe

[phldavies]

You could probably use SOME_VALUE_WE_DONT_CARE_ABOUT -> Unit and possibly Sonar would be happy with that?