getresourceasstream方法傳回空_Java和Kotlin互相調用的空安全問題

一次因為太菜導緻的巨大BUG

還記得去年實習做的最後一個項目，線上出現了巨大的崩潰，上報的crash率上升了快一個點...一度感覺要被狠批一頓了...不過前Leader人很好，慢慢解決問題，也沒有做什麼批評...

crash的原因比較簡單，是java裡面調用Kotlin函數導緻的。

舉個例子：

對Kotlin中這樣的方法

fun 
           

了解Kotlin的null-safety的話，我們知道這裡的參數是Kotlin中的

非空類型（也就是不帶問号的那個）

，在Kotlin的代碼中假設想要給這個方法傳入

可空類型

，在編譯階段就會報錯，提示必須傳入非空。

但是Java中并沒有空安全類型，沒有辦法在編譯階段确定引用是否為空，Java的引用任何情況下都有可能為null，在Java代碼中去調用kotlin方法如果傳入空指針，那麼編譯階段并不能發現問題，運作時Java這邊就會抛出NullPointerException。

日後吸取教訓，對于這樣的情況務必謹慎。

除了上面這個case，在了解之後，再來說說其他的類似情況。

實作接口時候可能傳來null

比如，如果SDK是Java，SDK内部定義的Listener或者Callback沒有顯式的使用

@Nullable

注解，業務方使用Kotlin實作SDK接口時，預設接口方法的參數為非空類型，但SDK内部可能傳回空的對象，導緻運作時異常。

Kotlin調Java可能傳回為空的函數

kotlin調用一個可能傳回為空的java函數，是不會提示空安全的，kotlin這邊認為得到的傳回值是一個非空類型。隻有加上@nullable之後才會提示傳回值可空。

使用一些類似Gson這樣的庫

我們定義這裡模拟一下一個從服務端請求來資料轉換實體類的過程

定義一個實體類，有一個非空類型的String：

data 
           

這邊我們假設服務端有這樣的資料傳回，我們Gson解析如下

編譯器會提示這個string不為空，但是的确有可能為空。

當然你說這裡我們把name定義成String?不就完了嗎。但是Kotlin設計的空安全特性這樣是不是就顯得過于雞肋...大家都是可空不就完了？是以應對這種情況，伺服器傳回為null可以稍微做一下處理，用反射，直接copy一段代碼學習一下：

/**
           

還有遇到的其他情況後續會做補充