首先看null和0的錯誤型別，比較典型的：
null 獲取不到物件，比如查詢hashMap，沒有查到對應鍵值的物件
0 除零錯誤
很明顯，null是程式的設計錯誤，因為程式本來就設計來執行在所有情況，如果這種情況下不應該存在一個物件，就會返回null，這時設計應該避免在後面直接使用null的，應該極力進行!=null判斷排除錯誤，使程式能正常執行
但是0就不一樣了，除零錯誤，或者Inf、NaN的問題，這個本來就是數學上的正常現象，如果出現這種錯誤，那是演算法的問題，是邏輯錯誤，沒有考慮零點、臨界點，這個在演算法上就應該規避，像數學上的分段方程一樣，在不同定義域上有不同值域，如果不考慮這個而想用一個方程表達，就會出現斷點的問題，這個不是程式語言產生的問題，頭疼的不應該是碼農，而是設計師和架構師
null的問題也是可以規避的，比如編寫時，如果要返回null的時候就返回一個全域性物件，一旦指向一個物件以後就不用去管會不會觸發異常，但是這樣寫，資料寫到全域性物件裡了，而沒有寫到希望的物件上，程式繼續執行，到最後結果一看，希望改的物件什麼都沒有改，而全域性變數早就被其他資料覆蓋了，不知道為什麼會這樣，查也查不到，最後發現是hash演算法寫錯了，應該返回希望的物件卻返回到全域性物件了，但是這種情況下用null就很好了，程式一下就崩潰了，或者列印“null錯誤”了（如果寫了!=null的分支處理），然後就知道null返回了，是hash演算法寫錯了
除了在編碼時規避，編譯器想要努力規避null也是不錯的發展，不知道未來編譯器在應該返回null的時候會怎麼做，期待更新的技術出現吧。但無論如何，程式總是返回你編寫的期望的東西，就算有技術處理null的問題，在null的時候，大多數情況下還是需要自己編寫程式碼，猜想可能和try catch一樣，在應該注意的地方提醒程式設計師注意null的問題，並且在出現未定義null處理的時候進行預設處理
程式和編譯器本來就是應數字處理而生的，應該遵循數學邏輯，也要滿足數學的需要，所以不可能排除0而單獨做出一個型別
首先看null和0的錯誤型別，比較典型的：
null 獲取不到物件，比如查詢hashMap，沒有查到對應鍵值的物件
0 除零錯誤
很明顯，null是程式的設計錯誤，因為程式本來就設計來執行在所有情況，如果這種情況下不應該存在一個物件，就會返回null，這時設計應該避免在後面直接使用null的，應該極力進行!=null判斷排除錯誤，使程式能正常執行
但是0就不一樣了，除零錯誤，或者Inf、NaN的問題，這個本來就是數學上的正常現象，如果出現這種錯誤，那是演算法的問題，是邏輯錯誤，沒有考慮零點、臨界點，這個在演算法上就應該規避，像數學上的分段方程一樣，在不同定義域上有不同值域，如果不考慮這個而想用一個方程表達，就會出現斷點的問題，這個不是程式語言產生的問題，頭疼的不應該是碼農，而是設計師和架構師
null的問題也是可以規避的，比如編寫時，如果要返回null的時候就返回一個全域性物件，一旦指向一個物件以後就不用去管會不會觸發異常，但是這樣寫，資料寫到全域性物件裡了，而沒有寫到希望的物件上，程式繼續執行，到最後結果一看，希望改的物件什麼都沒有改，而全域性變數早就被其他資料覆蓋了，不知道為什麼會這樣，查也查不到，最後發現是hash演算法寫錯了，應該返回希望的物件卻返回到全域性物件了，但是這種情況下用null就很好了，程式一下就崩潰了，或者列印“null錯誤”了（如果寫了!=null的分支處理），然後就知道null返回了，是hash演算法寫錯了
除了在編碼時規避，編譯器想要努力規避null也是不錯的發展，不知道未來編譯器在應該返回null的時候會怎麼做，期待更新的技術出現吧。但無論如何，程式總是返回你編寫的期望的東西，就算有技術處理null的問題，在null的時候，大多數情況下還是需要自己編寫程式碼，猜想可能和try catch一樣，在應該注意的地方提醒程式設計師注意null的問題，並且在出現未定義null處理的時候進行預設處理
程式和編譯器本來就是應數字處理而生的，應該遵循數學邏輯，也要滿足數學的需要，所以不可能排除0而單獨做出一個型別