This code again produces a StackoverflowError, as CircularRef.toString() continues recursing forever. ⤷ `Foo.toString()`Ī simpler, more condensed version of the same problem can be illustrated as follows: data class CircularRef( var ref: CircularRef? = null) This leads to an ever growing call-stack. Since Foo is a data class, its toString() implementation calls the same method on its member properties too. Let's look at a few more examples to illustrate problems with circular references. While this is bug is easy to fix, the problem is that this code fails at runtime, thus silently breaking Kotlin's non-null types.Ĭonsider starring this issue to get more attention to this problem: KT-44633: Circular object references silently break Kotlin's non-nullable types More Circular Reference Madness Therefore, constructor of Mercedes references a yet-uninitialized LewisHamilton variable, and leads to a null value being stored in a non-nullable variable. Its constructor references another lazy variable Mercedes, whose constructor has a circular reference to LewisHamilton. LewisHamilton gets initialized upon its first-access in main. If you run this example on Kotlin Playground, it produces the following output: Driver(name=Sir Lewis Hamilton, teamId=merc)Ī null value snuck into a non-nullable type. Val Mercedes: Team = Team( "merc", listOf(Drivers.LewisHamilton))Īlthough innocuous at first glance, this code breaks Kotlin's non-nullable types.
Val LewisHamilton: Driver = Driver( "Sir Lewis Hamilton", ) They break code at runtime, and are difficult to guard against at compile time.Ĭonsider the following example: data class Driver( val name: String, val teamId: String)ĭata class Team( val id: String, val drivers: List) Breaking Kotlin's Null-Safety with Circular ReferencesĬircular object references can be dangerous.
0 kommentar(er)
