java開發中對異常的處理

        最近入職一家新公司，第一周遇到一個人帶着做項目，本來以為是帶着熟悉一下業務，沒想到被鄙視了。問我以前公司的時候也這麼寫代碼？我當時比較蒙，确實不熟悉業務，于是接受了批評，表示以後一定改。

但是沒過5分鐘，我突然想明白了，和他去說自己的想法，得到的回複是，你現在應該适應現在，然後再改進，我說行！他說的沒錯，但是我覺着有些問題雖然沒有明确的對錯，但是會有每個人的理由。下面說一下我遇到的問題和争論的焦點。

       我做的是Java EE的controller層的編碼，使用的是zk架構，他們建議我在controller裡對每個對象在使用之前都要做為空的判斷，我覺着也有道理。但是争論的焦點在容器類和判斷後的處理，我的觀點是：

一、對于容器類，使用前可以不判斷，我的理由是所有傳回值是容器類的方法永遠都不應該傳回null，而是應該用空容器替代，如果傳回null，那麼就是方法的bug；

二、在controller層，如果判斷為空了，那麼就一定要做完善的處理，不能簡單的用這種方式

if(some == null){

       return;

}

或者

if(some != null){
   dosomething;
}
           

for(Object o:List){
    if(o==null){
       continue;
    }
}
           

 及時加上log日志，這種做法我覺着還不如不做判斷的方案更好，理由是，做了這種處理掩蓋了錯誤，雖然可以能夠提供所謂的穩定性，但是對于業務和将來問題的排查産生重大問題。

在controller層不做為空處理，當資料有問題時會報錯誤，咱們加個500的錯誤處理頁面展示給使用者，人家知道你犯錯誤了，會做其他處理；但是如果用上述方法掩蓋了問題，雖然不會報錯了，但是使用者也沒有得到想要的結果，而且還不知道為什麼會這樣。

在for循環裡，做跳過處理，其實是自作主張的删除了一條記錄，雖然這個是非法資料，但是我們也沒有權利掩蓋掉。

這樣做，給我的感覺是程式員為了避免所謂的bug，給系統增加了更大的風險。不加日志會難于排查将來的系統業務問題，即使加了日志，對于使用者來說也會造成困擾。

如果覺着非要處理掉所有的null，那麼我覺着應該在出現null的地方給使用者一個裡的提示，如果沒有提示，那麼請不要掩蓋可能的錯誤或者異常，因為使用者有知情權，程式員不該為了所謂的穩定性，用掩耳盜鈴的方式處理null，尤其是在controller層。

異常處理其實是編碼過程最難的部分，如果功力不夠深，就讓錯誤盡量的暴露出來，不丢人。

從開發效率來說，從我個人的經驗來說，建議在controller層盡量減少不必要的null判斷，在寫服務的時候寫的藥盡量穩定，藥處理掉各種情況。

寫的比較亂，歡迎看懂的朋友拍磚。本人虛心接受