1
votes

I have an abstract class with an unimplemented method numbers that returns a list of numbers, and this method is used in another val property initialization:

abstract class Foo {
  val calcNumbers = numbers.map(calc)
  def numbers: List[Double]
}

The implementing class implements using a val expression:

class MainFoo extends Foo {
  val numbers = List(1,2,3)
}

This compiles fine, but at run time it throws a NullPointerException and it points to the line of val calcNumbers:

[error] (run-main-0) java.lang.ExceptionInInitializerError
[error] java.lang.ExceptionInInitializerError
...
[error] Caused by: java.lang.NullPointerException
...

However when I changed the implemented method to def, it works:

def numbers = List(1,2,3)

Why is that? Does it have something to do with initialization order? How can this be avoided in the future as there is no compile time error/warning? How does Scala allow this unsafe operation?

1
missing s in number?Andrey Tyukin
@HüseyinZengin that seems somehow too vaguely related, no? Another non-duplicate: Scala initialization order of vals (there, the OP simply swapped order of vals, no abstract classes, no def-by-val override). A somewhat better duplicate: NPE when overriding parameterless method with a field, but the answer could be much more detailed.Andrey Tyukin
@AndreyTyukin Well you are right about the question itself not being a exact duplicate but this question is basically a result of early init. and the answer is perfectly covering this question IMHOHüseyin Zengin

1 Answers

3
votes

Here is what your code attempts to do when it initializes MainFoo:

  1. Allocate a block of memory, with enough space for val calcNumbers and val numbers, initially set to 0.
  2. Run the initializer of the base class Foo, where it attempts to invoke numbers.map while initializing calcNumbers.
  3. Run the initializer of the child class MainFoo, where it initializes numbers to List(1, 2, 3).

Since numbers is not initialized yet when you try to access it in val calcNumbers = ..., you get a NullPointerException.

Possible workarounds:

  1. Make numbers in MainFoo a def
  2. Make numbers in MainFoo a lazy val
  3. Make calcNumbers in Foo a def
  4. Make calcNumbers in Foo a lazy val

Every workaround prevents that an eager value initialization invokes numbers.map on a non-initialized value numbers.

The FAQ offers a few other solutions, and it also mentions the (costly) compiler flag -Xcheckinit.


You might also find these related answers useful:

  1. Scala overridden value: parent code is run but value is not assigned at parent.

  2. Assertion with require in abstract superclass creates NPE