最近公司內要搞乙個平台，內部涉及到自動化運維的一部分，趁著十一這兩天玩過回來在學習expect，看tcl一章異常處理的時候，突然想到個問題，異常合理處理方式的問題。
異常合理從技術上分2種處理方式。
1、拋exception的方式；
2、返回值判斷的方式；
其實任何系統中，都不可能只用一種處理方式，不然這個就過猶不及的，總結了一下比較合理的方式。
返回值判斷的方式比較適合於正常邏輯的一部分，哪怕對於某個業務功能來說，它可能影響很大，比如檔案不完整，賬戶不存在，密碼不正確，金額為負數等。
拋異常則適合於出錯了有可能無法繼續往下執行的場景，比如配置檔案不存在，資料庫連線不上，網路斷開。此時呼叫者必須仔細思考是否捕獲異常，清一色往上拋是不負責的做法。
除此之外，有可能會出現的情況就是乙個程式中有可能會丟擲七八種異常，這個時候，如果都通過丟擲異常的方式讓外部捕獲，這個實現就比較差了，而且並不一定所有的異常都是不可修復的。
還有很重要的一點，對於可能返回null的場景，內部沒有檢查是否為null，而是依賴於執行時的nullpointerexception總覺得不是一種特別合理的方式。因為nullpointerexception是個繼承於runtimeexception，這使得異常捕獲是可選的。真到執行時丟擲很可能會導致業務中止而不一致。對於這個null，更合理的做法應該是對於邏輯已知有可能為null而導致外部呼叫者使用null返回值可能會異常的（比如des/base64加解密），或許更好的方式是丟擲乙個包裝的受檢異常，強行要求外部呼叫者捕獲，而不是外部呼叫者判斷返回值是否為null（應用開發者很有可能是不會去看原始碼的），這可能是更好的方式。對於非open source程式，在自定義的受檢異常上包裝自定義的錯誤**這會更加的清晰。
Java異常處理方式
平時在開發的時候避免不了的出一些大大小小的不同型別的錯誤，這時候，對於這些異常怎麼處理呢，顯得至關重要了。採用try.catch.方式 trycatch exception e catch filenotfoundexception e catch ioexception e 採用throw丟擲 i...
異常處理方式 丟擲處理
異常的處理方式2 丟擲處理.throw throws 1.如果乙個方法內部丟擲了乙個異常物件，那麼必須在方法上宣告丟擲 2.如果呼叫了乙個宣告丟擲異常型別的方法，那麼呼叫者必須要進行處理，否則編譯報錯 3.乙個方法遇到了throw關鍵字，那麼該方法會馬上停止執行。4.在一種情況下只能丟擲一種異常物件...
異常類及處理方式
說句實話我沒怎麼聽懂，因為我太菜了。所以我只編了前乙個異常類，不太清楚兩者之間有什麼區別。一下附上 package com.huang public class fileexception extends exception catch exception e finally 以下為執行截圖 下乙個...