原文出處：
曉風輕
程式設計師你為什麼這麼累？
對於大型it系統，最怕的事情第一是系統出現了異常我不知道，等問題鬧大了使用者投訴了才知道出問題了。第二就是出了問題之後無法找到出錯原因。針對這2個問題，說說我們專案組是怎麼樣規定異常處理的。
再次宣告我的觀點，我這系列貼裡面，沒有什麼技術點，都是一些程式設計的經驗之談，而且是建立在專案背景是大部分**都是簡單的crud、開發人員流動大水平一般的情況下。希望讀者的重點不要再關注技術點。大部分工作中不需要什麼技術，你只要把**寫好，足夠你輕鬆面對！
言歸正傳，說回第乙個問題，系統出異常了我不知道，等問題鬧大了使用者投訴了才知道。這個問題出現非常多，而且非常嚴重。我不知道其他公司有沒有這種場景，對我們公司而言，經常會出現使用者反饋、投訴過來說某個功能不可用，開發人員定位分析之後，才發現之前的某一步出錯了。公司業務流程非常複雜，和周邊系統一堆整合，一堆的後台佇列任務，任何一步都可能出問題。
舉幾個今年真實的案例：
1. 某系統銷戶無法成功，最後定位發現前段時間ldap密碼修改沒有更新
2. 某個流程失敗，最後發現整合的系統新增加了nas盤，防火牆不通無法訪問導致報錯。
3. 某個功能無法使用，檢視日誌發現後台定時任務已經停了好幾天。
針對這些功能，在流程上當然可以採取相對的策略來保證，但從開發的角度來說，任何規定都無法保證一定不會發生錯誤，老虎也有打盹的時候，我只相信**。
貼一段非常常見的**，大家覺得這段**有沒有問題？
在我看來，這段**很多時候問題特別大！
丟掉了異常。異常就算列印了堆疊，也不會有人去看的！除非使用者告訴你出問題了，你才會去找日誌！所以，看著好像很嚴謹的**，其實作用並不大
異常處理再加上框框2處的空判斷，天衣無縫的避開了所有正確答案。本來需要更新文件，結果什麼錯誤沒有報，什麼也沒有做。你後台就算打了日誌堆疊又怎麼樣？
所以，我對開發人員的要求就是，絕大部分場景，不允許捕獲異常，不要亂加空判斷。只有明顯不需要關心的異常，如關閉資源的時候的io異常，可以捕獲然後什麼都不幹，其他時候，不允許捕獲異常，都丟擲去，到controller處理。空判斷大部分時候不需要，你如果寫了空判斷，你就必須測試為空和不為空二種場景，要麼就不要寫空判斷。
強調，有些空判斷是要的，如：引數是使用者輸入的情況下。但是，大部分場景是不需要的（我們的it系統裡面，一半以上不需要），如引數是其它系統傳過來，或者其他地方獲取的傳過來的，99.99%都不會為空，你判斷來幹嘛？就拋乙個空指標到前台怎麼啦？何況基本上不會出現。
新手最容易犯的錯誤，到處捕獲異常，到處加空判斷，自以為寫出了「健壯」的**，實際上完全相反。導致的問題，第一**可讀性很差，你如果工作了看到一半**是try-catch和空判斷你會同意我的觀點的，第二更加重要的掩蓋了很多錯誤，如上面的例子！日誌是不會有人看的，我們的目的是盡早讓錯誤丟擲來，還有，你加了空判斷，那你測試過為空的場景嗎？
web請求上的異常，不允許開發人員捕獲，直接拋到前台，會有controller處理！見
我的編碼習慣 - controller規範
所以上面的**，我來寫的話是這樣的，清晰明了。
另外一種後台定時任務佇列的異常，其實思路是一樣的，有個統一的地方處理異常，裡面的**同樣不准捕獲異常！然後異常的時候郵件通知到我和開發人員，開發組長必須知道後台的任何異常，不要等使用者投訴了才知道系統出問題了。
另外，開發組長需要自己定義好系統裡面的異常，其實能定義的沒有幾種，太細了很難落地；
異常不要繼承exception，而是繼承runtimeexception，否則到時候從頭改到尾就為了加個異常宣告你就覺得很無聊。
總結：開發組長定義好異常，異常繼承runtimeexception。
不允許開發人員捕獲異常。（異常上對開發人員就這點要求！異常都丟擲到controller上用aop處理）
後台（如佇列等）異常一定要有通知機制，要第一時間知道異常。
少加空判斷，加了空判斷就要測試為空的場景！
這篇文章，我估計一定有很多爭議，這些規則都和常見的認識相反，我在公司裡面推廣和寫貼分享的時候也有人反對。但是，你要知道你遇到的是什麼問題，要解決的是什麼問題？我遇到的是很多異常本來很簡單，但由於一堆健壯的try-catch和空判斷，導致問題發現很晚，可能很小乙個問題最後變成了乙個大事件，在一些it系統裡面，尤其常見。大家不要理解為不能加空判斷，大家見仁見智吧。反正我是這樣寫**的，我發現效果很好，我很少花時間在除錯**和改bug上，更加不會出現前台返回成功，後台有異常什麼也沒有做的場景。
最後對新手說一句，不要養成到處try-catch和加空判斷的惡習，你這樣會掩蓋掉很多錯誤，給人埋很多坑的！
編碼習慣之異常處理
對於大型it系統，最怕的事情第一是系統出現了異常我不知道，等問題鬧大了使用者投訴了才知道出問題了。第二就是出了問題之後無法找到出錯原因。針對這2個問題，說說我們專案組是怎麼樣規定異常處理的。再次宣告我的觀點，我這系列貼裡面，沒有什麼技術點，都是一些程式設計的經驗之談，而且是建立在專案背景是大部分 都...
Java開發編碼異常習慣處理
1.錯誤的捕獲方式 在捕獲了異常之後什麼都不做，相當於忽略了這個異常。千萬不要使用空的catch塊，空的catch塊意味著你在程式中隱藏了錯誤和異常，並且很可能導致程式出現不可控的執行結果。如果你非常肯定捕獲到的異常不會以任何方式對程式造成影響，最好用log日誌將該異常進行記錄，以便日後方便更新和維...
良好的編碼習慣
1 以簡潔明瞭的方式編寫c程式。通常把這種程式編寫方法稱為kis 保持簡潔 不要用古怪的方式編寫程式。3 計算機和編譯器是很好的教員。如果對c的某個特點沒有把握，編寫乙個簡單的程式，然後編譯並執行它，看看會發生什麼結果。4 在每乙個函式的前面加上描述函式用途的注釋。5 執行列印操作的函式所列印的最後...