Skip to content

Commit b38c07a

Browse files
committed
State problem more explicitly
I feel this is the required editing to make the point explicit.
1 parent 9f9804e commit b38c07a

File tree

1 file changed

+14
-5
lines changed

1 file changed

+14
-5
lines changed

tutorials/FAQ/initialization-order.md

Lines changed: 14 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,10 @@ disqus: true
77
partof: FAQ
88
num: 9
99
---
10-
Consider the following.
10+
11+
## Example
12+
To understand the problem, let's pick the following concrete example.
13+
1114
```scala
1215
abstract class A {
1316
val x1: String
@@ -25,12 +28,18 @@ class C extends B {
2528

2629
println("C: " + x1 + ", " + x2)
2730
}
28-
// scala> new C
29-
// A: null, null
30-
// B: hello, null
31-
// C: hello, dad
3231
```
32+
Let's observe the initialization order through the Scala REPL:
33+
```
34+
scala> new C
35+
A: null, null
36+
B: hello, null
37+
C: hello, dad
38+
```
39+
40+
Only when we get to the constructor of `C` are both `x1` and `x2` initialized. Therefore, constructors of `A` and `B` risk running into `NullPointerException`s.
3341

42+
## Explanation
3443
A 'strict' or 'eager' val is one which is not marked lazy.
3544

3645
In the absence of "early definitions" (see below), initialization of strict vals is done in the following order.

0 commit comments

Comments
 (0)