Lesson learned: don't use an

init

block inside of an

abstract class

🤦‍♂️

Can you elaborate?

Deployed a release that tested just fine on my end, then started getting a bunch of crash alerts for

Attempt to invoke interface method <name> on a null object reference

that I couldn't reproduce

Is not that is terrible using an init block in an abstract class, you just should not touch open/abstract properties/functions that are expected to be override in the derived classes. I believe the IDE warns you anyways.

That's a fair point. The IDE doesn't warn me about it though, at least in a class that looks something like this:

abstract class SomeAbstractClass(
    scope: CoroutineScope
) {

    protected abstract val someVal: SomeType

    init {
        scope.launch {
            someVal.someFunction()
        }
    }
}

Ah I see, interesting. The no warning make sense because the launch block won't execute synchronously. However, if you use a dispatcher that executes the launch block immediately in the executing thread, it will crash. It would be good to file for an enhancement in the syntax highlighting area.

Yeah my guess is we were just running into race conditions on certain devices where the coroutine would execute either before or after the abstract val in the subclass was initialized. I'll look into filing an enhancement. Thanks!

Looks like there is no warning when abstract function or value is used not in constructor scope exactly. For example, here it does not warn about anything too:

fun exec(block: () -> Unit) { block() }

abstract class SomeAbstractClass {

    protected abstract val someVal: String

    init {
        exec {
            someVal.length
        }
    }
}

It seems like so, the warning should trigger whenever a property name is found within init{}, regardless of scope. Perhaps giving the option to disable if the developer is aware of what is doing.

the warning should trigger whenever a property name is found within init{}, regardless of scope

I would say no. Counter use case I run into commonly is something along the lines of

abstract class Thing<T> : Observable<T> {
    abstract val value: Stuff

    init {
        addListener { doSomething(it, value) }
    }
}

Which is perfectly valid, as the lambda will not be executed till later.

Well, I suspect there is a lot of code looking like that. In such a case, it is hard to determine whether or not to warn. Then, another alternative is leave it up to the official documentation. Red letters as soon as you open the inheritance docs page 🤷🏻