Java 判断空操作

印象中是这样（为什么不自己跑一下啦…有的时候不一定是这个问题

理解是没错的

@ycfung 是同事让我不要这么传，免得 app 崩溃了，感觉挺沙雕的

这是 app 的老大难问题，后来传 null 来怎么办，总不能到处判断。
所以我改用 kotlin 了。app 是希望从源头上，避免空值的产生吧。

后来=后台

这不是傻。Java 里面的 null 甚至被其发明者认为是错误的设计。

https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions

对于强类型的语言而言，Optional<T> 其实更优雅，因为语义上就会提示调用者这返回值可能是空。

https://lw900925.github.io/java/java8-optional.html

字段加 @JsonInclude(JsonInclude.Include.NON_NULL)属性就好了，序列化时会过滤掉
但传个 null 也会 app 崩溃，确实很沙雕

纠正一下，那个不是属性，是注解，手误打错了

经常这样：“ app 改的话还要发新版本，服务器改是最快的”。

@ipwx 设计如此，但好像记得出现了 谁使用谁判断的原则

很多安卓开发人员懒得写问号，也懒得补默认值，于是乎就崩溃了

@kuyuzhiqi 你这个原则是建立在 Java 作为强类型语言却有 Null，而且因为早期没有 Optional，所以大量开发人员不保证不传回 Null 这一事实基础上的。

如果随处要检查 null，会带来巨大的开销。现代 CPU 都有流水线，一个 if 条件判断会打断流水线，造成几十倍的性能损失。虽然 Java 有牛逼的 JIT，对于大部分情况下不返回 null 的接口，很多时候可以弥补这一性能损失，但是如果一开始就不需要判断 if，岂不美哉？

@ipwx 像实体的话如果默认不为空岂不是实体多了就很占内存

@kuyuzhiqi 不不不，引用 /指针其实没问题，但是可以设计为，不能把 null 赋予一个引用 /指针。即，一个引用 /指针的初始化必须是有东西的。如果你想表示一个可能是空的东西，就用范型叠加，比如 Optional<T>。

当然，Java 的范型是补丁打上去的，是个 shit，这是另一回事情了。

@kuyuzhiqi 至于 Optional<T>，可以设计为内置功能而不是打补丁打上去的类。这样的话也不会有多少效率损失，字节码层面完全可以进行编译期优化。当然这就变成另一个语言而不是 Java 了。

如果是 Java 的话，那就只能靠约定了。虽然我觉得 Optional<T> 的约定很舒服，可是也并不是所有人都认同这种用法，就没办法了。

Optional 了解一下

java8 新增 Optional,可以处理这种情况

java8 好多特性包括 Optional 安卓要 SDK24 以上才支持....安卓还是老老实实 Kotlin

@ipwx 说得振振有词，那么：if(a !=null)，跟 if(a.isPresent)，或者 a.ifPresent(()->{bulabula})，到底损失了多少性能呢； Optional.get()是不是永远不会抛出 NullPointException 呢；在序列化 json 的时候，你要怎么处理 Optional 字段呢。

null 到底是强类型语言的特性，还是弱类型或无类型语言的特性呢。

@passerbytiny 所以我说了嘛，如果要超级好用的 Optional （包括解决性能问题），得要别的语言，反正不能是 Java。

@passerbytiny 呃，想了想也说不定。说不定哪天 JVM 的 JIT 特别牛逼，处理 Lambda 就和 inline 性能没区别了，那 Optional 就能用了。

至于 Optional.get() 抛不抛异常，别用它不就行了（当然这一点看上去没戏，Java 库的历史包袱太重）。还有序列化，当然 Optional 字段不存在就不输出啊。

可以用 optional 或者用 jsr305 的 nullable, nonnull 等打标记

intellij 会在做分析

Optional 不就是在语言 /库层面把楼主说的准则给强制实施了吗。。。

@ipwx 真得建议你，不光别用 Java，任何编程语言都别用了。哪天突然想起来，0 既不是正数也不是负数，所以凡是跟数学相关的东西也别用了。

我觉得任何一个稍微有上进心的人都会在同事这么提醒的时候去查一查原因，而不是张口就骂傻逼。

@ech0x 测试把问题给他了，他推给我，我看他没做空判断，提醒了下他，他说这么简单让我改下，我就说了我的想法，然后问后台的字段为 null 怎么办，他说不不用担心，肯定不会随便骂人的

这时候又要感谢 Anders Hejlsberg 了

还是 kotlin 好