こう言うのがあって。
class Hoge { public static void main(String[] args) { Object hoge = null; hoge.toString(); } }
実行すると当然NPEになるんだけど、こんな感じで出る。
% java Hoge.java Exception in thread "main" java.lang.NullPointerException: Cannot invoke "Object.toString()" because "<local1>" is null at Hoge.main(Hoge.java:8)
一昔前は Cannot invoke "Object.toString()" because "<local1>" is null なんて出なかったんだけど、 JEP 358: Helpful NullPointerExceptions で出るようになりました。LTS基準で考えると導入されたJava17は2021年9月なので、使ってたりするところも多くなっているんじゃないかなと。
「 null になりえるところでは null チェックしましょう」には異論はない。そして null チェックしてくれる Objects#requireNonNull(T) とかもJSLにはある。
IDEも「これ null になるからチェックしたまへ」と警告出してくれるし、quick fixで requireNonNull で包むのも候補に出てくる。とはいえ……
import java.util.Objects;
class Hoge {
public static void main(String[] args) {
Object hoge = null;
- hoge.toString();
+ Objects.requireNonNull(hoge).toString();
}
}
こうするのはイマイチなんだ。IDEの警告は消えるけど、警告をなくすだけの臭いものに蓋をして熟成させる対応であり、あまりよくない。
なんでかって言うと、この実行結果はこうなってしまう。
% java Hoge.java Exception in thread "main" java.lang.NullPointerException at java.base/java.util.Objects.requireNonNull(Objects.java:233) at Hoge.main(Hoge.java:10)
スタックトレース増える。けど、必要な情報ではない。何もしなければ出てくるJEP 358よりも情報が減っている。文字数が増えて情報量が減る、酷い話だ。
コード量も requireNonNull を書くことで増えている。でも「hoge が null であってはいけない」なんてのは続くメソッド呼び出しでわかってる話でしかないので、情報量はあまり増えていない。「null じゃないはずなんだ！」と言う主張は感じなくはないので役に立つ可能性もわずかにはあるけれど、機械的な警告消し対応（表出した事象の叩き潰し での「警告を消せ」に対する「誤った対応」 ）であれば主張なんてないので、読み取っても誤読にしかならない。
以上により、私は 引数が1つの requireNonNull は役に立たない と思っている。役に立たないどころか、使わない方がマシまである。JEP 358のメッセージが出ているほうが役に立つ。
まぁ requireNonNull はJava1.7で導入されたものだし、 if や条件演算子で null チェックするよりはまぁってこともあったわけだけども。
と言うことで、どうせ使うなら引数2つの方を使いましょう。第二引数にエラー時のメッセージを込められる。
import java.util.Objects;
class Hoge {
public static void main(String[] args) {
Object hoge = null;
Objects.requireNonNull(hoge, "hogeがnullのままここにきてしまった。宇宙線の仕業？").toString();
}
}
% java Hoge.java Exception in thread "main" java.lang.NullPointerException: hogeがnullのままここにきてしまった。宇宙線の仕業？ at java.base/java.util.Objects.requireNonNull(Objects.java:259) at Hoge.main(Hoge.java:8)
こうなっていれば、このエラーに遭遇したときに「これ実装した人は疲れてたんだなぁ」と言うのがわかる。
以上のように nullになった場合のことを考慮したメッセージを第二引数に書いたrequireNonNull > JEP 358によるデフォルトメッセージ > 引数1つのrequireNonNull
である以上、引数1つのを使ってたら検出するように静的解析設定した方がいいかもなぁと思ったりする今日この頃。requireNonNull のJavadocに書いてるような、コンストラクタで引数をフィールドに代入するときとかのようにメソッド呼び出しが続かない時には適切だと思うんだけども。
とかなんとか書いたけど、これ以前に null になり得るコードを避けるべきという前提があり、自分で書かずとも null になりえるパラメタやレスポンスを受けるなら早期エラーにするかさっさと Optional とかで包んで適切に扱いましょう、と言う話はある。
null 滅びないかなぁ。
追記
似たようなこと書いてた。
Java14以降ではObjects#requireNonNull(Object) メソッドや自身で null チェックしての例外送出より、そのままNPEを起こした方が解析しやすいまであります。予期しないNPEには備えるんじゃなく、予期しないnullを教えてくれるNPEを素直に受け止めるのがいいと思います。
2021年よりは使われてる環境も多くなってるだろうし、改めてって感じでヨシとしとく。
