A class extending its inner class throws a NullPointerException

Compiler
1 
@main def pdt={}
class C extends o.CI:
  class CI
val o=C()

compiles in 3.4.0 but throws

java.lang.NullPointerException
        at C$CI.<init>(pdt.scala:3)
        at C.<init>(pdt.scala:2)
        at pdt$package$.<clinit>(pdt.scala:4)
        at pdt.main(pdt.scala:1)

at runtime. Wouldn’t a compile-time error be a more intuitive behavior?

2

Yes, it’s might be unintuitive, but it’s mostly due to code transformation happening to top-level statements.
However, it is possible to check proper initialisation of these under Scala 3.4 using -Ysafe-init-global (do not confuse it with -Ysafe-init existing in all Scala 3 releases). Just be aware that these 2 are still an experimental flags, and might sometimes lead to false-positives

> scala-cli run main.scala -O -Ysafe-init -Ysafe-init-global -S 3.4
[warn] ./main.scala:2:1
[warn] Access uninitialized field value o. Calling trace:
[warn] ├── @main def pdt={}     [ main.scala:1 ]
[warn] │   ^
[warn] ├── val o=C()    [ main.scala:5 ]
[warn] │         ^^^
[warn] └── class C extends o.CI:        [ main.scala:2 ]
[warn]     ^
3

fwiw, note that Scala 2 errors on this with “illegal cyclic reference involving class C”

I don’t see how it matters here that top-level statements are involved in the originally posted code. Scala 3.4.0 still errors at runtime if you wrap the whole thing to not be top-level anymore:

scala> object O:
     |   class C extends o.CI:
     |     class CI
     |   val o=C()
     | 
// defined object O
                                                                                                    
scala> O.o
java.lang.NullPointerException
  ... 35 elided
4

I don’t see how it matters here that top-level statements are involved in the originally posted code

I simply didn’t want to get into the details. Top-level statement are converted to an object, like the one you presented above, so it’s expected that is still fails (it also gives the same warnings under -Ysafe-init-global).
I believe it would be very beneficial from the users perspective that stuff like -Ysafe-init-global would be enabled by default in Scala 3 once they’re stable.

5 Likes
5

Seth recently made the same comment (“works in Scala 2!”) on a similar ticket.

I haven’t tried my example from the ticket, but VerifyError beats NullPointerException every time (in rock, paper, scissors).

1 Like
6

I also didn’t want to get into the details, but I was curious about why the exception has no message text. First, though, I was curious about the Scala 3 REPL wrapping because of the clinit in the OP stack trace. Then, second, my curiosity evaporated. I guess it’s lazy module val all the way down? but it’s not trivial to ask the REPL to tell me directly. In Scala 2, I would :javap to verify that I’m not misreading -Vprint trees.

My clever remark was going to be that it’s not necessary to “wrap” inside a REPL session, which always wraps (somehow).

Welcome to Scala 3.4.2-RC1-bin-SNAPSHOT-git-e54be6e (21.0.2, Java OpenJDK 64-Bit Server VM).
Type in expressions for evaluation. Or try :help.

scala> class C extends o.CI:
     |   class CI
     | val o=C()
java.lang.NullPointerException
  ... 35 elided

scala> throw null
java.lang.NullPointerException: Cannot throw exception because "null" is null
  ... 33 elided

scala> null.asInstanceOf[String].length
java.lang.NullPointerException: Cannot invoke "String.length()" because "null" is null
  ... 33 elided

Anyway, it’s reassuring to know that, at the end of the day,

"null" is null
7

I think that regardless of the safe-init flags, this specific piece of code should just give an illegal cyclic reference error like Seth said.

2 Likes