Multiple modern programming languages, including Kotlin, Scala, Swift, and C#, have type systems where nullability is \emph{explicitly} specified in the types. All of the above also need to interoperate with languages where types remain \emph{implicitly nullable}, like Java. This leads to runtime errors that can manifest in subtle ways. In this paper, we show how to reason about the presence and provenance of such nullability errors using the concept of \emph{blame} from gradual typing. Specifically, we introduce a calculus, $\nullc$, where some terms are typed as \emph{implicitly nullable} and others as \emph{explicitly nullable}. Just like in the original blame calculus of Wadler and Findler, interactions between both kinds of terms are mediated by \emph{casts} with attached \emph{blame labels}, which indicate the origin of errors. On top of $\nullc$, we then create a second calculus, $\nullcs$, which closely models the interoperability between languages with implicit nullability and languages with explicit nullability, such as Java and Scala. Our main result is a theorem that states that nullability errors in $\nullcs$ can always be blamed on terms with less-precise typing; that is, terms typed as implicitly nullable. By analogy, this would mean that \texttt{NullPointerExceptions} in combined Java/Scala programs are always the result of unsoundness in the Java type system. We summarize our result with the slogan \emph{explicitly nullable programs can’t be blamed}. All our results are formalized in the Coq proof assistant.

The artifact is a Coq formalization of the results in the paper.