hey, a bug report was submitted to me with something that looks like this:

sealed class Foo : SomeInterface1, SomeInterface2 {
    @kotlinx.serialization.Serializable
    object A : Foo() {
        private fun readResolve(): Any = this
        override fun hashCode() = /* ... */
    }

    @kotlinx.serialization.Serializable
    object B : Foo() {
        private fun readResolve(): Any = this
        override fun hashCode() = /* ... */
    }

    @kotlinx.serialization.Serializable
    object C : Foo() {
        private fun readResolve(): Any = this
        override fun hashCode() = /* ... */
    }

    fun doTheThing(baz: List<String>): String = when (this) {
        A -> /* ... */
        B -> /* ... */
        C -> /* ... */
    }
}

the bug report was a

kotlin.NoWhenBranchMatchedException

thrown from

doTheThing()

. how could this be? is this necessarily a kotlin bug?

I have sometimes seen issues like this when using mocks in tests. If a mocking framework is generating an implementation of

Foo

, it could end up with an instance that isn't one of the required subclasses.

Use

data object

instead of object. What's happening is that the object is being recreated I think

@Youssef Shoaib [MOD] I didn't know about that feature, interesting. however, going over the feature description, it seems like this is only syntax sugar for auto-implementing

toString()

,

equals()

and

hashCode()

, right? so if if we already implement

hashCode()

(hopefully correctly) and even

readResolve()

, would there be any difference with using a

data object

? @Sam thanks - no mocking involved afaik

equals

is what matters here I believe. That's why the when is failing

oh, I see. is this fixable without going to

1.9

(which we might not want to do - not my decision)? is it as simple as adding the following boilerplate?

override fun equals(other: Any?) = hashCode() == (other as? A)?.hashCode()

(and same for

B

and

C

)

Yes the is check should do the trick, but make sure you override hashcode as well

@Youssef Shoaib [MOD] just to be clear - the minimal change here would be to add

is A ->

branches in the

when

? no

equals()

override required?

Yes that's the most minimal change you can make, just

is A ->

I see. thanks a lot.

By the way, comparing hashcodes is not the right way to implement equals. Two objects are allowed to have the same hashcode even when they're not equal.

@Klitos Kyriacou yes, however the

as?

check would then return

null

in that case (which means, the actual equality here is on the type and the check with the hashcode is superfluous)

Even then, if

this.hashCode()

happens to return 0, it will equal

null.hashCode()

so will give an incorrect

true

result.

woah, that's right!

Actually, I misread it:

(other as? A)?.hashCode()

would be

null?.hashCode()

so it will be comparing

0

with

null

, which is

false

so it would give the right answer anyway.

object

doesn't override

equals

, so it doesn't rely on `hashCode`; it's purely the default

equals

, which is instance-based

so (as previously mentioned), would

is

be the preferred way of making sure all instances of the same `object`s test the same?

it's a bit awkward but yes

Easiest way is to use

data object

it handles all of that because it overrides equals and hashcode

you can do some tricks with

readResolve

to ensure Java serialization doesn't return non-singleton instances, if you think that's what your users are running into, but there's no way to protect against reflection

we do believe this is a serialization thing (by "we", I mean people here more knowledgable about this than me)

currently your readResolve is simply passing through the newly-created instance. instead it should look like

object A {
    private fun readResolve(): Any = A
}

if you want to ensure that only the singleton

A.INSTANCE

exists (after the serialization machinery)

@ephemient that

readResolve()

implementation is probably it! thanks for catching it