引言
之前寫過一篇文章《在企業級開發中使用Try...Catch...會影響效率嗎？》一文，得到了不少朋友的關注，自己也與大家私下交流了一些東西。
為了最快的讓大家明白本文的內容，我先把本文的內容列個提綱，提綱如下：
Try...Catch中大家普遍認為的結論
盡可能的考慮真實環境的再次做測試並進行分析
之前文章中有錯誤的幾點內容
總結
正文部分
第一部分
對於之前的文章，大家的主要意見有如下：
Try...Catch不會有性能問題
Try...Catch會對性能有一定的影響
對我的測試結果有爭議
測試沒有考慮所有環境，如預熱、網絡異常等等
不應該用異常處理來作為邏輯處理
還是主觀上感覺try...catch還是會有性能影響，但是到底會有多大，不好說。
置疑“企業級開發”這個概念
第二部分
針對以上的一些問題，本著沒有困難，創造困難也要上的精神，筆者又做了一些測試，但是考慮到真實環境，及可能出現的問題，代碼或多或少有所改動。考慮到的因素有：
throw new Exception("Kevin讓我異常了");這個異常拋出方法是拋出普通的異常方法，而實際開發中，可能出現的異常類的數量都非常的龐大，筆者粗略的估計了一下，可能至少得有上千種，而且還可以自定義異常類，如果按照這個來算的話，異常類的數量應該是無窮的。
異常類有的處理起來時間會長，有的處理起來時間會短，有朋友認為網絡處理方面的異常處理起來可能時間會稍長一些，一旦用try...catch的話，處理起來時間可能會長。
如果說一個函數的Try...Catch的性能損耗時間比較短，那麼1000個函數的性能損耗會不會很長？比如，系統中有1000個函數，每個函數中都有一個try...catch,然後又一個方法調用了這1000個函數。 針對這一點，就可以把try...catch...放在for循環裡喜歡1000次來進行測試。
測試中的預熱問題，盡可能的多考慮真實環境。
針對以上問題，筆者盡可能的換些異常類進行測試，然後將try...catch...放到for循環中進行測試。測試得到如下結論：
沒有使用try...catch不出現異常跟使用了try...catch不出現異常 時間相當。
try...catch...的時間=從執行函數開始到出現異常的時間+異常捕獲的時間+異常處理的時間。而異常捕獲的時間通常微乎其微，如果是單次的話，可以忽略不計，也不會造成性能瓶頸。
如果只做異常捕獲，但是不做異常處理的話，循環1000次出現異常的時間約是使用了try...catch不出現異常的391.9倍。
因為異常處理的時間由多個部分組成，因為不同異常捕獲到的時間可能不同，異常處理的時間也不盡相同，就會導致最後時間加起來結果跟我測試的會有差別。
在進行以下的分析之前，筆者也請大家認真的思考兩個問題：
什麼問題算性能問題？
什麼是性能瓶頸？
第三部分
糾正之前文章中的幾點錯誤：
try...catch...會造成一定的性能損失，但並不是比不用try...catch...性能要高。
數據庫操作使用事務比不使用事務要速度快的問題。
關於數據庫操作使用事務比不使用事務快的問題，得分兩個方面來考慮：
如果是一個人操作的話，使用事務會比不使用事務要快。
如果是多個人操作，使用事務就不一定快了，道理很簡單，使用事務的話，是利用鎖來進行並發控制的，如果盲目的認為使用事務快，而濫用事務，那麼就可能導致很嚴重的性能問題，多個用戶進行並發操作的時候，全部被一個人鎖住了，得一個一個的來，可想而知，極有可能會因為濫用事務而造成性能瓶頸。筆者之前沒有考慮到第二點，不過值得慶幸的是，我也從來沒有濫用過事務。
第四部分
總結：
Try...Catch...會損耗一定的性能，但不會造成性能瓶頸。
建議使用try...catch。
盡可能的考慮到可能存在的異常並進行處理，盡可能的少出現異常或不出現異常。
不要濫用數據庫事務提高性能，這樣可能會造成並發訪問的性能問題或性能瓶頸。
不要使用try...catch進行流程處理。
如果可能的話，盡量要把循環寫在try...catch內部，而不要把try...catch放到循環內部。
如果是try...catch中套著try...catch，異常處理機制是從內部的try...catch...往外部拋的，最先是在內部進行捕獲、處理。
關於測試。雖然測試還是不能完全的達到真實環境，實際上真實的環境也是錯綜復雜的，很難完全兼顧，但至少目前的測試來說，筆者認為，還是達到了我想要的目的。
關於什麼是企業級開發？筆者也只是有個模糊的概念，從Google上搜索到了一下一段，與大家分享下吧：
企業級開發主要是針對企業級應用的開發。
那麼什麼是企業級應用呢？
企業級應用是指那些為商業組織、大型企業而創建並部署的解決方案及應用。這些大型企業級應用的結構復雜，涉及的外部資源眾多、事務密集、數據量大、用戶數多，有較強的安全性考慮。
當代的企業級應用決不可能是一個個相互獨立的系統。在企業中，一般都會部署多個彼此連接的、相互通過不同集成層次進行交互的企業級應用，同時這些應用又都 有可能與其它企業的相關應用連接，從而構成一個結構復雜的、跨越Intranet和Internet的分布式企業應用群集。
此外，作為企業級應用，其不但要有強大的功能，還要能夠滿足未來業務需求的變化，易於升級和維護。
實際上看到這裡，大家可能對企業級開發有一個粗略的認識了，雖然概念已經給出，可是對於理解什麼是企業級開發，還是有一些困難。可能有的人也會問，概念都給你了，為什麼還這麼難理解？實際上筆者認為，看待某個問題，得從多個方面來看，才理解的深刻，如當你問什麼是唯心主義，實際上唯心主義是針對唯物主義來進行定義的，當你不明白唯心主義的時候，恐怕也是很難區分清楚唯物主義的。
就像企業級應用是按照什麼分類的？難道還有個人級開發......？
最近博客園流行幾個新詞：”吉日風格“、”吉日風格的水貼“，可是究竟什麼是吉日風格，滿足什麼條件才算吉日風格？滿足什麼條件又算是水貼？
其實這些都是非常主觀的的概念，既然很主觀，就沒必要去深究了。
