Let it crash, 早死早超生, 这才软件设计的终极哲学.

当发生 NullPointerException 时说明问题已经超出下层的处理范围了, 事态已经无法控制了.

这种时候最应该做的就是及时上报, 让上面赶快派有能力处理的来赶快处理一下.

要是你隐瞒不报, 自作聪明编个数据保证系统不崩, 任由 null 不断传播, 污染各种各样的外部系统

等最后发现返回结果不对, 花大力气层层追查, debug 打一万个断点, 读出来到处都是错误数据, 而原始问题已经找不出来了.

这时候程序早已病入膏肓, 回天无力. 剪不断, 理还乱, 还是赶快推翻重写吧.

话说这周有个大笑话, Java 程序在升级 MacOS 14.4 之后全崩了,

因为 JVM 以前判定 null 有个小优化是根据访问受保护的内存页是否返回 SIGSEGV (因为走SIG 性能好)

但是呢, 苹果大受 Let it crash 哲学启发, 决定将访问受保护内存改为发 SIGKILL, 于是现在只要出现 null, 整个进程就直接炸了.

该问题影响 JDK 8 到 JDK 22 所有编译出的 Java 程序, 且从理论上就无法修复, 笑死人了.

更搞笑的是就算你手动写 if obj != null, JDK 觉得你压根不懂优化, 也会被强行变成同样的保护访问, 然后被当场 kill.

也就是说你判定会直接挂掉, 你不判定迟早会挂掉, 早死晚死, 总归要死, 哈哈哈哈.